Stupid Event Sourcing Symfony Laravel Package

Product Decisions This Supports

• Event-Driven Architecture (EDA) Adoption: Enables teams to transition from traditional CRUD-based systems to an event-sourced model, improving auditability, scalability, and real-time capabilities. Aligns with roadmaps for modernizing legacy systems or building greenfield projects requiring strong consistency and traceability.
• Build vs. Buy: Avoids reinventing event-sourcing infrastructure from scratch, reducing development time and technical debt. Ideal for teams lacking deep expertise in CQRS/ES but needing production-grade reliability.
• Use Cases:
  • Auditability & Compliance: Track every state change in financial, healthcare, or regulatory systems.
  • Real-Time Systems: Power live updates (e.g., dashboards, notifications) via event projections.
  • Decoupled Services: Enable asynchronous communication between microservices without tight coupling.
  • Data Reconstruction: Rebuild aggregates or views from historical events (e.g., recovering from corruption).
• Symfony Ecosystem Synergy: Leverages existing Symfony projects (e.g., API Platform, Doctrine) to integrate event-sourcing with minimal friction, reducing adoption barriers.

When to Consider This Package

• Adopt When:

  • Your team prioritizes temporal query capabilities (e.g., "Show me all changes to Order #12345 since 2023").
  • You need strong consistency without sacrificing performance (via DBAL-backed event storage).
  • Your project uses Symfony and you want to avoid vendor lock-in (e.g., EventStoreDB, Axon).
  • You require simple, opinionated event-sourcing without complex setup (e.g., no need for Kafka/RabbitMQ).
  • Your domain involves high-frequency writes (e.g., IoT, gaming) where event logs must scale horizontally.

• Look Elsewhere If:

  • You need eventual consistency or distributed event sourcing (consider Kafka + EventStoreDB).
  • Your team lacks PHP/Symfony expertise (steep learning curve for CQRS/ES patterns).
  • You require advanced event versioning or conflict resolution (e.g., CRDTs).
  • Your use case demands low-latency event processing (this package is DBAL-bound, not in-memory).
  • You’re building a serverless or multi-cloud system (deployment complexity may arise).

How to Pitch It (Stakeholders)

For Executives: "This package lets us adopt event-sourcing—a battle-tested pattern for building scalable, auditable systems—without the overhead of custom development. Think of it as ‘Git for your data’: every change is logged as an immutable event, enabling real-time updates, easy debugging, and seamless recovery from failures. For example, in our [X] project, this would let us [Y business outcome, e.g., ‘comply with GDPR by tracking user data changes’ or ‘launch a real-time fraud detection system’] with 60% less dev effort. It’s a low-risk way to modernize our architecture while keeping costs predictable."

For Engineering: *"This is a lightweight, Symfony-native wrapper for stupid-event-sourcing, which stores events in DBAL (no external dependencies). Key benefits:

• Zero setup: Just add the bundle, configure Doctrine, and start emitting events.
• Console tools: Built-in commands to replay events, rebuild projections, or debug aggregates.
• Flexible projections: Use Doctrine queries or raw SQL to materialize views (e.g., for API responses).
• Symfony integration: Works seamlessly with Doctrine, API Platform, and Messenger.

Tradeoffs:

• Not distributed (single DB bottleneck), but perfect for monoliths or co-located microservices.
• Simpler than Axon or EventSauce, but lacks some advanced features (e.g., snapshotting).

Proposal: Let’s prototype this for [specific use case, e.g., ‘the Order service’] in 2 sprints. If it meets our needs, we can scale it to [other services]."*