Weave Code
Event Sourcing Bundle Laravel Package
patchlevel/event-sourcing-bundle
Symfony integration for the patchlevel event-sourcing library, built on Doctrine DBAL. It bundles snapshots, stream splitting, versioned subscriptions, upcasting, personal-data crypto-shredding, schema/migration setup, and CLI commands for a smooth developer experience.
An event sourcing bundle, complete with all the essential features, powered by the reliable Doctrine ecosystem and focused on developer experience.
Frequently asked questions about Event Sourcing Bundle
- Can I use patchlevel/event-sourcing-bundle in a Laravel application?
- Not directly. The bundle is a Symfony integration: its DI extension, configuration tree, tagged services and console commands will not load in a Laravel container. What you can reuse is the underlying patchlevel/event-sourcing library on a Doctrine DBAL connection, with the bundle serving as a reference implementation for wiring config, commands and subscriptions. Expect to write a thin Laravel service provider and adapter yourself, and budget for that work explicitly rather than treating it as a composer require.
- What is the difference between the patchlevel/event-sourcing library and the bundle?
- The library contains the actual event sourcing domain code: aggregates, the event store, snapshots, split streams, subscriptions, upcasting and crypto-shredding. The bundle is the Symfony glue that registers those services, exposes a config tree and adds CLI commands plus schema and migration helpers. That separation is the main reason the exit cost stays bounded if you keep your own framework adapter small.
- How do I install patchlevel/event-sourcing-bundle?
- Run composer require patchlevel/event-sourcing-bundle and, in a Symfony app, apply the Flex recipe so the bundle is registered and a default configuration file is created. Without the recipe you need to register the bundle manually and follow the installation chapter of the bundle documentation, including the config tree for the DBAL connection and the event store schema. There is no Laravel package discovery step, so a Laravel install is a manual adapter job, not a supported installation path.
- Does it conflict with the Symfony components Laravel already pins?
- Possibly, and this needs testing before you commit. The bundle requires Symfony components such as console, serializer and uid, and those version constraints can collide with the Symfony packages Laravel itself depends on through its own components. Resolve this in a short spike with a locked composer.json and verify the minimum viable dependency set, because trimming optional Symfony dependencies at the adapter layer is often cheaper than fighting the resolver.
- How do I create the event store tables and manage schema migrations?
- The bundle ships schema management helpers and integrates with Doctrine Migrations, so the event store tables are usually created and evolved through that toolchain. In a Laravel app that means a second connection beside Eloquent and a second migration tool, and you should decide explicitly who owns the store schema and what the upgrade contract is when the package changes tables. A common compromise is to generate the SQL once and replay it through Laravel migrations so the rest of the app keeps a single migration entry point.
- How do subscriptions and projections work, and how do I run them in production?
- Subscriptions are versioned, managed consumers of the event stream that track their position in the store, which is what you use for projections and processors. They are typically driven by long-running worker processes started from CLI commands, so in production you need supervision, graceful shutdown handling and monitoring for gaps or stalls. If you run them under Laravel's queue worker instead, wrap the subscription run loop carefully and keep the checkpoint state inside the event store rather than the queue.
- How does crypto-shredding protect personal data?
- Personal data in events is encrypted with per-subject keys, so deleting a subject's key renders their data unreadable while the rest of the stream stays intact. That is useful for GDPR erasure requests without rewriting the immutable event log. You need to design where keys live, how they integrate with your KMS or key store, and how key deletion is audited, because losing a key is functionally identical to shredding the data.
- What is upcasting and when do I need it?
- Upcasting converts old event payloads into the current shape as they are read, so you can evolve event classes without rewriting stored history. You need it as soon as your first event schema changes on a store that already holds production data. Plan the versioning convention and add an upcaster for each breaking change, and test the conversion path against realistic old payloads.
- Are snapshots and split streams worth using?
- Snapshots store a serialized aggregate state at a given stream version so rebuilding an aggregate does not replay the whole history, which matters once streams grow to hundreds or thousands of events. Split streams let you break a large aggregate into a root stream plus related streams, keeping load times and write contention down. Both are optional, but designing aggregates with them in mind early is much cheaper than retrofitting later.
- Is patchlevel/event-sourcing-bundle production-ready, and what are the Laravel alternatives?
- The code quality looks solid, the package is MIT licensed, fully typed and actively released, but adoption signals are thin, with roughly fifty GitHub stars and effectively no dependents outside the vendor's own work. That makes it a single-vendor dependency you should treat as high risk in terms of roadmap alignment and bus factor, mitigated by keeping your framework adapter thin. If you want a native Laravel fit, compare it against Laravel-oriented event sourcing packages and, more importantly, against whether your bounded context genuinely needs event sourcing at all.
Weaver
How can I help you explore Laravel packages today?