Eventstore Bundle Laravel Package

Product Decisions This Supports

• Event sourcing / CQRS roadmap validation. This package is the cheapest possible way to answer "do we actually want event sourcing?" It exposes the minimum integration surface for appending and reading event streams, so a PM can scope a timeboxed spike before committing engineering quarters to a platform investment.
• Build-vs-buy on connectivity glue. The decision it frames is whether to own a small HTTP transport to EventStoreDB or depend on a maintained client. Given the package is archived, the honest output of this decision is almost always "buy maintained, or own the glue" — but the exercise forces the team to price the glue.
• Audit trail vs. full event sourcing. Many roadmap items that sound like event sourcing ("immutable history," "replay," "time travel") are satisfied by an append-only table. Evaluating this package sharpens the requirement: if the need ends at audit logging, EventStoreDB is overscoped and the cheapest decision is no event store at all.
• Dependency and vendor risk scoring. Archived, 5 stars, 0 dependents, zero upstream support is a textbook "risk accepted / avoid" entry for a technology radar. Useful as a reference point when setting the bar for what the team may adopt.
• Legacy modernization budgeting. If an existing Symfony service already talks EventStore over HTTP, this package quantifies the "we now own this fork forever" maintenance tax — a recurring cost line, not a one-time one.
• Go/no-go and shutdown decisions. It gives a PM a concrete artifact to close out: spike done, pattern understood, dependency rejected, decision documented.

When to Consider This Package

Consider it only when:

• You are running a short, throwaway spike to prove the event-sourced loop (append a stream, read it back, fold it) before funding a real build.
• You need a reference for EventStore's HTTP API shape — reading, not shipping.
• You're supporting a legacy Symfony application where the bundle's kernel/extension conventions still hold and the alternative is writing the same HTTP calls from scratch.
• No production traffic, no customer data, no security surface, and a clear "delete or own it" exit criterion decided before the spike starts.

Look elsewhere when:

• You are on Laravel. This is a Symfony bundle — no service provider, no facade, no publishable config. It is reference code, not a dependency, and the "Laravel/PHP" framing of the candidate list is wrong for this package.
• You need maintenance, security patching, or PHP 8+ / Guzzle 7 support. Archived means you are the maintainer from day one.
• You are greenfield. Modern EventStoreDB clients use gRPC; this pins you to a legacy HTTP/AtomPub surface.
• You need retry, backoff, idempotent appends, observability, or connection pooling as documented first-class features rather than Guzzle defaults.
• Procurement or compliance requires a versioned, actively maintained dependency with a release history.

How to Pitch It (Stakeholders)

For executives: This package is a small connector that lets PHP code talk to EventStoreDB — the database you'd adopt if the roadmap commits to event sourcing or a replayable audit trail. It is plumbing, not a platform. The critical fact for decision-making is that it is archived, has five stars and no known users, meaning no bug fixes and no security patching; whoever adopts it owns it permanently. My recommendation: use it as a cheap learning spike, never as something we ship. The real decision on the table is whether event sourcing belongs on the roadmap at all — and if it does, we budget for a maintained client or a small piece of glue we own and can swap to gRPC later. If we do not need event sourcing, the requirement is likely an append-only audit log a normal database table already satisfies, and we close this out and record it on our technology radar as "avoid — unmaintained."

For engineering:

• What it is: a Guzzle-based HTTP/AtomPub client for EventStoreDB, packaged as a Symfony bundle for Symfony 2/3-era kernels. There is no Laravel integration; in our Laravel services we would lift the client classes into an adapter we own, or skip it.
• Health: archived, ~5 stars, 0 dependents, no release cadence, no CVE response. Assume no PHP 8+ or Guzzle 7 support; expect conflicts and forks.
• Technical caveat: it targets EventStore's HTTP API, which is de-emphasized in favor of gRPC in current EventStoreDB. Even a successful integration bets on a declining transport, and offers no built-in idempotency on append — duplicate events are a real risk that our adapter must harden.
• Recommended path: timeboxed spike on our target EventStoreDB version → decide fork-vs-build on that evidence → if building, wrap behind an EventStoreClient interface we own so the transport can move to gRPC without touching domain code. For a Laravel build, evaluate a maintained gRPC client or a PHP event-sourcing library rather than this bundle.
• Ask from product: is event sourcing / CQRS on the roadmap, or is this an audit-log need in disguise? That answer determines whether we fund a spike with a permanent ownership line item, or close the candidate entirely.