Event Store Bus Bridge Laravel Package

Technical Evaluation

Architecture fit prooph/event-store-bus-bridge is thin glue, not a framework. It wires two heavier dependencies together: prooph/event-store (append-only event persistence with optimistic concurrency) and prooph/service-bus (command/event routing). Concretely it contributes an EventPublisher plugin that listens on EventStore::EVENT_APPEND_TO and forwards committed domain events to a MessageProducer, plus a TransactionManager that wraps command handling in an event-store transaction. That is a few hundred lines of code.

This matters for the evaluation: the architectural decision is "do we adopt prooph's CQRS/ES model?" — the bridge is a nearly free add-on. If we adopt prooph, the bridge is the correct wiring; if we don't, the bridge has no independent value. It is also strictly a write-side concern: it does nothing for read models, projections, HTTP, auth, or tenancy, all of which remain Laravel's job. Fit is therefore "acceptable but non-idiomatic." Laravel's own bus, event dispatcher, and queue are bypassed for the command/event path, which creates two parallel messaging paradigms in one codebase.

Integration feasibility Technically feasible. prooph is framework-agnostic and PSR-oriented (PSR-11 container, PSR-3 logger), so Laravel can host it: register prooph services in a service provider, back the event store with a PDO/Doctrine adapter over an existing database connection, and implement Prooph\Common\Messaging\MessageProducer as a thin adapter over Laravel's queue or event dispatcher. That adapter is the cleanest seam in the whole integration and is where I would put engineering effort.

The friction points are real but bounded: PHP version constraints (a 2021-08-26 release may cap at PHP 8.0 while current Laravel requires 8.1+) must be verified with composer why-not before committing; PSR-11 compatibility of Laravel's container should be confirmed rather than assumed; and the team must accept prooph's message, aggregate, and repository abstractions alongside Eloquent.

Technical risk High, and concentrated in the ecosystem rather than this package:

• Maintenance risk (primary). Last release 2021, no indication of active stewardship. The prooph ecosystem is effectively in maintenance mode; the original author's focus moved toward event-engine. 37 stars is a signal of a small, shrinking user base — fewer eyeballs, slower answers, thinner Stack Overflow coverage.
• Transitive risk. Adopting the bridge means adopting prooph/event-store and prooph/service-bus at pinned versions, including their DBAL/PDO adapters. Those are the components that will actually break on PHP/Laravel upgrades.
• Correctness risk. The bridge's event publication is not a true outbox. If publication targets an external broker or a queue that outlives the DB transaction, you inherit the classic dual-write hazard: events published but transaction rolled back, or committed events never published. The TransactionManager gives the illusion of atomicity; it does not provide it across a broker boundary.
• Low code volume cuts both ways. Small surface area is easy to audit and easy to fork or reimplement in-house — which is also a legitimate mitigation.
• License risk: none. BSD-3-Clause is permissive and commercially safe.

Key questions

1. Is event sourcing a genuine requirement (audit, temporal queries, replayable projections) or an architectural preference? If the latter, stop here.
2. Which event store backend — PDO/MySQL, Postgres, or Doctrine — and does it meet our durability and operational standards?
3. What is our exit strategy if the ecosystem goes fully dormant: fork the bridge, or replace it with ~200 lines of in-house glue?
4. Does the team have production CQRS/ES experience, or is this a learning project on a revenue path?
5. What are the event versioning/upcasting and replay requirements, and who owns them?
6. Have we compared ecotone/ecotone (Laravel-aware CQRS/ES), spatie/laravel-event-sourcing (lighter, idiomatic), and event-engine?
7. Are there regulatory or data-retention constraints on immutable event storage (GDPR erasure vs. append-only)?

Integration Approach

Stack fit Adopt a bounded-context posture, not a platform migration. Laravel remains the application shell: routing, auth, validation, read models via Eloquent, and queues via Horizon. prooph owns only the write side of one bounded context. Do not let prooph's bus become the application's default dispatcher — that is how teams end up with two competing architectures and no clear ownership.

Concretely: one Laravel service provider binds the event store, repository, command bus, and the bridge's EventPublisher/TransactionManager; one adapter class implements MessageProducer against Laravel's dispatcher or queue; projections are Laravel listeners or jobs writing to Eloquent tables.

Migration path Use a strangler-fig sequence. Start greenfield: pick a new aggregate in a domain where event history has clear business value (e.g., order lifecycle, ledger entries). Do not retrofit an existing CRUD table first — retrofitting forces you to invent history you never recorded and doubles the work. Keep legacy Eloquent paths untouched and run the new context behind a feature flag. Only after one context has survived a production quarter should a second be considered.

Compatibility Verify explicitly before any commitment: (a) the bridge and the pinned prooph/event-store and prooph/service-bus versions resolve against the target PHP and Laravel versions; (b) PSR-11 interop with Laravel's container, or plan a small adapter; (c) the chosen event-store adapter's database driver is supported by our managed DB offering; (d) PHPUnit/Pest compatibility for the event-sourced test suite.

Treat this as a go/no-go gate: composer require must succeed cleanly on the latest Laravel LTS before a spike begins.

Sequencing

1. Two-day compatibility spike: install, wire, persist and reload one aggregate against a scratch database.
2. One-week vertical slice: one aggregate, one command, one synchronous projection, one read endpoint, integration tests.
3. Hardening: outbox or transactional-messaging decision for the producer, snapshotting policy, event upcasting strategy, projection rebuild runbook.
4. Production trial with one context, flagged, with a documented rollback to the Eloquent path.
5. Only then evaluate a second context — by which point the team's opinion of prooph will be well-informed.

Operational Impact

Maintenance Assume we own this. Budget for a named maintainer and a scheduled quarterly dependency review that includes a fork-or-replace decision. Pin exact versions and commit the lockfile; do not float constraints on a dormant ecosystem. Keep the bridge's surface area small enough that an in-house reimplementation remains a plausible one-sprint task — that is the real insurance policy.

Support No commercial support. Answers come from a small community and from reading prooph's source. Our engineers will be the escalation path. This is acceptable for a bounded, flagged context; it is not acceptable for a system with a 24/7 uptime commitment and no in-house expertise.

Scaling The write side scales as the event store does: append throughput, optimistic-concurrency retries under contention, and index size on the events table. Long-lived aggregates need snapshots or command latency degrades. Projection rebuild time grows linearly with event volume — a full rebuild of a mature store can take hours and must be a rehearsed, non-blocking operation. The read side scales with Laravel, which is familiar ground. Expect the event store's growth rate to surprise stakeholders: append-only means storage never shrinks and audit retention policies compound it.

Failure modes

• Dual-write divergence between event store commit and message publication — the highest-severity risk; mitigate with an outbox table and a relay, or by making publication synchronous and inside the transaction until proven insufficient.
• Projection lag or stall — read models silently go stale; needs lag metrics and alerting, not just error logging.
• Poison events blocking a projection worker; requires dead-letter handling and a replay procedure.
• Optimistic concurrency exceptions surfacing as command failures under load; the API contract must express this honestly (409/retryable) rather than as a 500.
• Event schema drift when handlers evolve; without a versioning discipline, old events become unreadable and rebuilds fail.
• Upgrade lock-out — being pinned to a PHP version the rest of the platform has moved past, forcing an emergency fork.

Ramp-up Steep. CQRS/ES is a conceptual shift — aggregate boundaries, eventual consistency, idempotency, replay semantics — layered on an unfamiliar, sparsely documented library. Plan three to four weeks before a capable Laravel developer is productive and one full production cycle before they are confident in failure handling. Deliverables that make this tractable: a written decision record, a one-page internal primer on event versioning and projection rebuilds, and a reference implementation from the vertical slice that subsequent contexts copy. Do not staff this with the team's most junior engineer and a deadline.