Kurrentdb Core Laravel Package

Product Decisions This Supports

• Event-sourcing feasibility in a PHP/Laravel product. This package is the client-side integration layer that lets a PHP codebase talk to KurrentDB (formerly EventStoreDB), the event-store database. If your roadmap includes event sourcing, CQRS, or domain-event persistence, this is the library that determines how much of the integration is "solved" versus "bespoke."
• Build vs. buy for the event store. Choosing an HTTP client like this implies a broader architectural bet: you are buying an append-only event log as a product rather than building an event table in Postgres or a Kafka topic. That decision gates downstream choices about projections, read models, replays, and operational tooling — make it deliberately.
• Feature scoping for audit/compliance features. KurrentDB's append-only stream model maps naturally to audit trails, temporal queries, and "state as of a point in time." If your roadmap has compliance, regulatory audit, or history/undo features, this is a shortcut to implementing them — versus building an audit-log service from scratch.
• Where it fits vs. messaging. Event stores and message brokers overlap but are not the same. This supports the decision "do we need durable, replayable, ordered event history with per-stream semantics (KurrentDB) or fire-and-forget fan-out (RabbitMQ/Kafka)?" Choosing correctly saves rework on the outbox-pattern and replay tooling.
• Dependency footprint and architecture standards. As a thin HTTP API client, it pushes you toward a clean domain/event separation: your domain code emits events, an infrastructure layer persists them. That shapes module boundaries and testing strategy across the roadmap.
• What it does not decide. It is an infrastructure adapter, not an application framework. It won't answer questions about projection rebuilds, subscription checkpoints, or schema evolution — factor those into the roadmap as separate work regardless of this package.

When to Consider This Package

Consider it when:

• You have already chosen KurrentDB/EventStoreDB as the event backbone and your application tier is PHP/Laravel.
• You want HTTP-level access (rather than maintaining a gRPC client) and prefer a small, single-purpose adapter.
• You value a permissive license (MIT) and a maintained release cadence — releases through mid-2026 indicate active stewardship.
• You need a low-ceremony way to append to streams, read streams, and capture basic event-store semantics without writing and testing your own HTTP client, serialization, and retry logic.
• You are prototyping an event-driven feature and want to validate the integration cost before committing to a longer build.

Look elsewhere (or build your own adapter) when:

• Ecosystem depth is a hard requirement. With ~69 stars and zero dependents, there is effectively no third-party ecosystem, no community of users to lean on, and a narrow maintenance base. If you need guaranteed long-term support, prefer a more widely adopted client or plan to vendor and maintain the code yourself.
• Throughput or latency matters. The HTTP API adds overhead versus gRPC; high-frequency, low-latency event appends may need a different transport.
• You need batteries-included Laravel ergonomics. This is a core client, not a full framework integration — expect to provide service providers, configuration, connection lifecycle, and testing utilities yourself.
• You are not doing event sourcing. If your events are just messages between services, a broker plus an outbox table is simpler for most teams than introducing an event store and its operational overhead.
• Your platform is not PHP. The package is PHP-specific; the architectural decision (KurrentDB) can outlive the client choice, but this library won't help you elsewhere.

How to Pitch It (Stakeholders)

For executives: We're evaluating a small, MIT-licensed PHP client that connects our application to KurrentDB, an event-store database. It is a narrow integration piece, not a platform commitment on its own — it lowers the cost of adopting event sourcing and lets us build audit trails, history/replay, and event-driven features without writing custom database plumbing. The dependency itself is low-risk on licensing and cost, but the surrounding ecosystem is small, so we should treat it as code we may need to own and maintain. The real decision to weigh is architectural (do we want an event store at all?), and this package makes that option cheaper to try.

For engineering: It's a thin HTTP adapter over KurrentDB's API — stream appends, reads, and core event-store operations — with serialization and request handling handled for you. It saves you writing and testing a client from scratch, keeps our domain layer clean (emit domain events, infrastructure persists them), and is permissively licensed with recent releases. Caveats: low community adoption means we should pin the version, keep the wrapper behind our own interface so we can swap transports later, and budget for reading the source and handling any gaps (config, connection lifecycle, test doubles) ourselves. Recommend a time-boxed spike against a real KurrentDB instance before committing it to the roadmap.

For product: This unlocks event-driven features — audit history, as-of-date state reconstruction, and reliable domain-event replay — at a lower integration cost than building custom event storage. It does not, by itself, decide whether we go event-driven; that trade-off (complexity and operational overhead vs. auditability and replayability) is the product call, and this package mainly reduces the execution risk if we make it.