sydepsystem design atlas

Event Sourcing

Persist the sequence of events, derive current state by replay.

AdvancedData
Aggregate ServiceComputeEvent StoreMessagingProjectorAnalytics & DataCurrent-state ViewStorage

Instead of storing only current state, every state change is appended as an immutable event. Current state is a projection derived by replaying events, giving a full audit trail and the ability to rebuild any past view.

When to use it

  • You need a complete audit trail of every change, not just the latest value
  • Business rules benefit from being able to replay history to derive new views

Trade-offs

  • Querying current state requires a projection, not a simple row read
  • Schema evolution of events over time needs careful versioning

Components used

Managed App ServiceEvent StreamStream ProcessingDocument Database

How it works

  • Instead of storing current state, the system appends immutable events describing what happened. State is derived by replaying those events in order.
  • Snapshots periodically capture derived state so replay does not have to start from the beginning of time.
  • Projections build read-optimised views from the same event stream, which means new views can be constructed retroactively over historical events.

Used in the wild

  • Financial ledgers and accounting systems, where the audit trail is the product.
  • Domains where 'how did we get here' matters as much as the current value — order lifecycles, claims processing.
  • Systems that must answer questions about the past that nobody thought to ask when the schema was designed.

Good to know

  • Events are immutable, which makes schema evolution genuinely hard. You cannot migrate an event you already wrote, so every consumer must handle every historical version forever.
  • Deleting a user's data collides directly with an append-only log. The usual workaround is crypto-shredding: encrypt personal fields per user and destroy the key.