Practice : Event Sourcing

Purpose and Strategic Importance

Event Sourcing is an architectural pattern where state changes are captured as a sequence of immutable events. Rather than storing only the current state, the system records every change, enabling rich auditability, traceability, and flexibility in how data is interpreted and used over time.

This practice supports high-integrity systems, enables time travel and replay capabilities, and forms the foundation for reactive and event-driven designs. It also strengthens observability and provides a robust model for debugging and recovery.

Description of the Practice

  • Every change to application state is recorded as a distinct event (e.g. OrderCreated, PaymentReceived, UserEmailUpdated).
  • The current state is derived by replaying or projecting from these events.
  • Events are immutable and stored in an append-only log or event store.
  • Systems can build multiple projections (e.g. read models, analytics) from the same event stream.
  • Popular tools and frameworks: EventStoreDB, Kafka with Kafka Streams, Axon Framework, Akka Persistence, Marten (for .NET).

How to Practise It (Playbook)

1. Getting Started

  • Choose a bounded context where event sourcing can simplify history tracking, auditability, or complex workflows.
  • Design your domain events carefully - events should be meaningful, versioned, and business-aligned.
  • Use an event store that supports immutability, ordering, and replay.
  • Keep projections simple - treat them as disposable views of the event log.

2. Scaling and Maturing

  • Introduce snapshotting to avoid replaying large event histories on every load.
  • Use schema evolution strategies to handle event versioning gracefully.
  • Build audit dashboards and observability tools from raw event streams.
  • Support replay-based testing, analytics, and simulation.
  • Extend to CQRS (Command Query Responsibility Segregation) where appropriate for performance and decoupling.

3. Team Behaviours to Encourage

  • Model business processes explicitly through event design.
  • Embrace immutability and favour append-only updates to critical systems.
  • Share and reuse event schemas between services and consumers.
  • Document how state is built from events to aid onboarding and troubleshooting.

4. Watch Out For…

  • Over-engineering - not all use cases need event sourcing; avoid unnecessary complexity.
  • Incomplete tooling or limited operational experience with event-based systems.
  • Coupling between producers and consumers of events via shared assumptions.
  • Event explosion or duplication in poorly scoped bounded contexts.

5. Signals of Success

  • System history is replayable and transparent - no hidden state transitions.
  • Audit trails are complete and trusted by operations, product, and compliance.
  • New features (e.g. analytics, metrics) are derived from past events without schema changes.
  • Debugging and rollback are faster due to event traceability.
  • Domain experts and developers collaborate over shared understanding of events.