Event Sourcing Laravel Package

Product Decisions This Supports

• Build vs. buy for event sourcing / audit trail infrastructure. patchlevel/event-sourcing is a mature, actively maintained PHP/Laravel package that provides the core primitives (event store, aggregates, projectors, reactors, snapshots, subscriptions) so the team can avoid building and maintaining its own event store. Each minor release like 3.22.0 signals continued maintenance, reducing the "abandoned dependency" risk that often tips build-vs-buy decisions toward custom work.
• Roadmap planning for audit, compliance, and temporal data features. Because the package already handles event persistence, replay, and projections, PMs can sequence features like "full audit history," "as-of reporting," or "rebuild read models" as configuration/work on top of the library rather than as net-new architecture.
• Integration and interoperability decisions. The 3.22.0 enhancement ("Add header aliases," PR #914) gives teams flexibility in how metadata headers are named and mapped on stored events. From a product standpoint this reduces friction when integrating with external systems or evolving metadata contracts (e.g., correlation IDs, causation IDs, tenant/user identifiers) without breaking downstream consumers — supporting decisions to standardize event metadata across services.
• Prioritizing schema/metadata evolution work. Header aliasing means metadata naming can be adapted rather than requiring a hard migration, which can lower the cost and risk of data-contract changes in the roadmap.
• Low-risk incremental adoption. This is a minor, backward-compatible feature release (no breaking changes, no deprecations noted), so PMs can treat it as a safe dependency bump and factor it into routine upgrade cadence rather than a migration project.

When to Consider This Package

Adopt when:

• The domain has strong audit, compliance, or "how did we get here" requirements where an append-only event log is genuinely valuable.
• You are on Laravel/PHP and want first-class framework integration (service provider, Eloquent-backed storage, queue-friendly projectors/reactors) rather than a language-agnostic event store.
• You need read-model projections and eventual consistency patterns (CQRS) without assembling multiple libraries.
• The team has or can acquire event-sourcing expertise — this is an architectural commitment, not a drop-in CRUD helper.

Look elsewhere or defer when:

• The problem is simple CRUD or basic auditing that Laravel's built-in model events / activity-log packages can satisfy far more cheaply.
• The team lacks event-sourcing experience and has no near-term need for replay or projections — the operational and cognitive overhead is real.
• You need a polyglot or non-PHP event store, or a managed/hosted event-sourcing platform.
• Strict regulatory data-deletion requirements conflict with immutable logs and you cannot design around them (crypto-shredding, etc.).

On 3.22.0 specifically: the header-aliases enhancement is a minor convenience/ergonomics improvement. It does not change the adoption calculus on its own, but it is a positive signal of active maintenance and metadata flexibility.

How to Pitch It (Stakeholders)

For executives: We are evaluating patchlevel/event-sourcing as the foundation for our audit trail and event-driven features. It is an established, actively maintained Laravel package (latest 3.22.0 is a small, backward-compatible enhancement) that lets us deliver full history, replay, and reporting capabilities without building and maintaining that infrastructure ourselves. The main consideration is team expertise and architectural commitment, not vendor risk.

For engineering: This package gives us an event store, aggregates, projectors, reactors, snapshots, and subscriptions out of the box, aligned with Laravel conventions. Version 3.22.0 adds configurable header aliases (PR #914) — a low-risk enhancement that improves metadata interoperability and makes evolving event headers easier without hard migrations. No breaking changes or deprecations in this release. Recommendation: adopt if we are committed to event sourcing/CQRS for the target domain; otherwise a simpler activity-log approach may suffice.