Event Store Bundle Laravel Package

Product Decisions This Supports

• Audit trail and compliance requirements. An append-only event log gives you a defensible, replayable record of every state change — the kind of thing that shortens SOC 2 / GDPR / financial-audit conversations from "we think we can reconstruct it" to "here is the log."
• Build vs. buy vs. adopt for event-sourcing infrastructure. This package is a candidate for the "adopt" branch, but the newly published v2.2.0 narrows that: it removes the by_support implementation in a minor version bump, which tells us the public surface is still moving and semver is applied loosely. The decision is therefore "adopt as vendored source with a pinned version," not "adopt as a dependency we upgrade freely." The 1–2 engineer-quarters saved on writing an event store, projections, and replay tooling remain real, but the risk profile now needs an explicit line item for upgrade churn.
• Event-driven decoupling roadmap. If your roadmap includes moving from synchronous, tightly coupled service calls to domain events (order placed, subscription changed, page published), an event store is the substrate that makes that migration incremental rather than a rewrite. Budget a re-read of the source at each upgrade, since functionality can disappear between minor releases.
• Temporal and "as-of" reporting. Product questions like "what did this customer's plan look like on the date they were billed?" become answerable from the event stream instead of from fragile snapshot tables.
• Backfill and recovery capability. Replay is the operational lever: when a projection has a bug, you fix the handler and re-run history rather than hand-repairing data. This is a genuine reduction in incident cost and should be valued as such.
• Integration and webhook fan-out. Downstream consumers (analytics, CRM sync, notifications) can subscribe to the event stream instead of being wired into the write path, which lowers the cost of adding each new consumer.

When to Consider This Package

Consider it only when all of the following hold:

• You have a concrete, near-term need for event sourcing proper — replay, temporal queries, or multiple independently-evolving read models — not merely "we want an audit log." Event sourcing is an architectural commitment, not a library you sprinkle on; the cost is in the model, the team's fluency, and the schema governance, not the dependency.
• You have verified framework fit. The repository is landingi/event-store-bundle and the "bundle" terminology points at Symfony, not Laravel. If you are on Laravel, confirm the package actually integrates (service provider, container bindings, config publishing) before it enters a design doc — a mismatched integration would consume the savings many times over. Note that v2.2.0's change is to a support-oriented feature, which reinforces that this is an extraction of one company's application concerns rather than a framework-neutral event store.
• You are comfortable vendoring or forking. With zero stars, zero dependents, and a single-vendor origin, treat this as source code you are adopting, not a dependency you are consuming. Budget for reading it end to end and for owning patches.
• You accept unstable versioning. v2.2.0 removed a feature (by_support) in a minor release. Pin exact versions, keep a diff review step on every upgrade, and do not build domain behavior on top of anything you haven't read. Assume any surface can be deleted at any time without a major-version signal.
• Your team has, or will build, event-sourcing competence: versioning events, handling schema evolution, idempotent consumers, and projection rebuild strategy. Without that, the package becomes an expensive append-only table nobody trusts.
• The scope you need is genuinely small — one bounded context, a handful of aggregates.

Look elsewhere when:

• You only need audit logging or change history. spatie/laravel-activitylog or owen-it/laravel-auditing solve that at a fraction of the conceptual cost. Choosing event sourcing for audit alone is a well-known over-engineering trap.
• You need community, documentation, or a support path. Zero stars and zero dependents mean no Stack Overflow answers, no third-party tutorials, no one to ask. Compare against EventSauce, Spatie's event-sourcing package, Broadway, or Prooph — all of which have real ecosystems and years of production scars.
• You need a security or maintenance SLA, or you operate in a regulated environment where unmaintained transitive dependencies are a finding.
• You need API stability guarantees. v2.2.0 is evidence that breaking removals ship in minor versions; if your roadmap depends on a stable contract, this is not it.
• The package's release cadence and provenance still can't be characterized. v2.2.0 is a meaningful data point — the package is not abandoned, it is being actively changed — but a single PR removing an internal-flavored feature is churn, not a track record. You still cannot distinguish "actively maintained for us" from "actively maintained for someone else's domain."

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed event store extracted from Landingi's own production system. It offers a credible shortcut to audit trails, replayable history, and an event-driven architecture — capabilities that typically cost a quarter or two of engineering to build. The latest release, v2.2.0, is a mixed signal worth naming plainly: the project is alive and shipping, which removes the "abandoned" risk we previously carried; but the change removes functionality in a minor version, which means we cannot assume stable APIs and would own the upgrade-review cost ourselves. Combined with near-zero external adoption and a single corporate maintainer, my recommendation is unchanged and slightly reinforced: pilot it inside one bounded context with a documented exit path and a pinned version, rather than standardize on it. If the pilot proves out, the option value is real; if it stalls, we have lost weeks, not quarters. The decision to do event sourcing at all is the larger commitment and deserves separate scrutiny — this package is a tactical choice downstream of that strategic one.

For engineering: Evaluate as a fork, not a dependency, and pin the version. Start by confirming framework fit — the repo is landingi/event-store-bundle and the "bundle" naming suggests Symfony; validate against our Laravel stack before anything else. Read v2.1.0 → v2.2.0 as a case study: a feature was deleted in a minor bump, so check what by_support did, whether anything in our design would have depended on it, and what that implies for the rest of the surface. Then check test coverage, event serialization format, and whether projection rebuild is supported. Benchmark it against Spatie's event-sourcing package and EventSauce on the two dimensions that matter to us: upgrade path and how much we'd have to write ourselves. Timebox the spike; report back with a build-vs-adopt delta rather than a yes/no.