Event Sourcing & CQRS

The log as the system of record

Event Sourcing flips the usual model: instead of storing current state and overwriting it, you store the full sequence of state-changing events as the source of truth. Current state is a fold over that history. Kafka is a natural event store — an append-only, replayable, partitioned log is exactly what event sourcing needs.

Benefits: a perfect audit trail, the ability to rebuild any projection by replay, and time-travel debugging ('what did this account look like on March 3?'). Cost: you must handle schema evolution of old events forever, and 'current state' requires a fold or a snapshot.

CQRS — separate the write and read models

Command Query Responsibility Segregation pairs naturally with event sourcing: the write side validates commands and appends events; one or more read sides consume those events and build projections optimised per query (a search index, a denormalised SQL view, a cache, a graph). The read models are disposable — drop and rebuild from the log. This is why a single event stream can feed Postgres, Elastic and a vector DB simultaneously, each shaped for its own queries.

Implement the core of event sourcing: a pure reducer that folds an event history into current account state. The same events could build any number of other projections.