Event Sourcing & CQRS Vocabulary

Event Sourcing is a fundamentally different approach to persistence — events ARE the database.

Traditional (state-based) persistence:
• You store the current state: {"orderId": "123", "status": "shipped"}
• To update: overwrite the row with new state
• History is lost — you can't see the previous statuses

Event Sourcing:
• You store events: OrderPlaced → PaymentReceived → OrderShipped
• To get current state: replay all events through an aggregate
• Complete history is preserved — every state change is recorded

Benefits of Event Sourcing:
• Complete audit trail — you know every state transition and when it happened
• Temporal queries — reconstruct state at any point in time
• Event replay — rebuild projections, fix bugs, backfill new read models
• Debugging — the full history of what happened is always available

Costs:
• More complex to implement than simple CRUD
• Queries require projections (not simple SQL SELECTs)
• Schema evolution is harder (events are immutable)

Key vocabulary:
• Event store — the append-only database that stores the event sequence
• Append-only — events are never updated or deleted, only new events are added
• Event replay — rebuilding current state by processing all historical events

Projections are how event-sourced systems answer queries efficiently.

Since the event store only contains an immutable event stream (not queryable state), projections transform events into queryable read models.

How a projection works:
① Subscribe to the event store (or consume events from a stream)
② Process each event and apply the relevant transformation:
OrderPlaced → insert new row into order_summary table
OrderShipped → update status column in order_summary table
③ The resulting table is the read model — optimised for fast queries

Advantages of projections:
• One event stream → multiple projections → multiple specialised views
• Can be rebuilt from scratch by replaying the full event history
• Projections can be optimised per query (denormalized, pre-computed aggregates)

Key vocabulary:
• Projection — the process of building a read model from events
• Read model — the queryable data structure produced by a projection
• Projector — the code/service that runs the projection
• Rebuild / backfill — dropping and recreating a read model by replaying all events
• Catch-up subscription — a projection catching up on events it missed (e.g. after downtime)

CQRS + Event Sourcing is a powerful combination because each pattern solves the other's biggest challenge.

Why CQRS pairs well with Event Sourcing:
• Event Sourcing makes writes easy but reads hard (you can't query an event stream efficiently)
• CQRS solves this by building projections → read models on the query side

CQRS architecture:

User action  →  Command  →  [Command Handler]  →  [Aggregate]  →  Event Store
                                                        ↓
                                                    [Projector]  →  Read Model DB
Query        ←  [Query Handler]  ←  Read Model DB

Write side (Command side):
• Receives commands, validates business rules via aggregates
• Writes domain events to the event store
• Optimised for consistency and correctness

Read side (Query side):
• Projections build read models from the event stream
• Read models are denormalized, cached, and optimised for specific queries
• Optimised for performance and scalability

Key vocabulary:
• Command bus — routes commands to the appropriate command handlers
• Query bus — routes queries to the appropriate query handlers
• Write model — the aggregate + event store (consistency-focused)
• Read model — the projection output (performance-focused)

This is one of the most compelling advantages of Event Sourcing — bugs in read models are fully recoverable.

Recovery steps for a buggy projection:

① Fix the projection code — correct the bug in the aggregation/transformation logic
② Drop the affected read model — delete the incorrect data from the read model database
③ Reset the projector to position 0 — point it at the beginning of the event store
④ Replay all events — the projector processes the full event history with the fixed logic
⑤ Read model is rebuilt — all data is now correct, as if the bug never existed

Why this is possible:
• The event store is append-only and immutable — the source events are always correct
• Read models are derived, not the source of truth — they can be discarded and rebuilt
• Events carry timestamps — you can rebuild to any point in time

Key vocabulary:
• Event replay — reprocessing all stored events to rebuild state
• Projector reset — pointing the projector back to the beginning of the stream
• Position 0 — the start of the event stream (first event ever stored)
• Read model rebuild — dropping and recreating a read model via event replay

GDPR + Event Sourcing is a genuine engineering challenge with established solutions.

The tension:
• Event Sourcing requires immutable, append-only events
• GDPR Article 17 (Right to erasure) requires the ability to delete personal data

Solution 1: Event Tombstoning
• When erasure is requested, publish a PersonalDataErased event
• The original PII events remain in the stream but projections treat the tombstone as overriding them
• Projections rebuild with the PII replaced by null/redacted values

Solution 2: Crypto-Shredding (preferred)
• When creating user events, encrypt all PII fields with a user-specific encryption key
• The key is stored separately in a key management service (KMS)
• For erasure: delete only the encryption key — the events remain in the store but PII is now irretrievable ciphertext
• Event sequence integrity is preserved; no events are modified or deleted

Key vocabulary:
• Crypto-shredding — making data irretrievable by deleting its encryption key
• Event tombstone — an event that signals previous events should be treated as erased
• Right to erasure — GDPR Article 17: the right of data subjects to have their personal data deleted
• Data minimisation — collecting only the PII strictly necessary in events (reduces GDPR surface area)