Event sourcing

Each entity, such as an order or an account, gets its own stream: the ordered events that record every change to it. To handle a command, the application reads the stream, replays the events to rebuild the current state (“rehydration”), checks its rules and appends new events. Events are never edited: a mistake is undone by appending a compensating event, such as ReservationCanceled after SeatsReserved. When streams grow long, a snapshot of the state every N events lets the application replay only what came after it; the snapshot is a cache, and the events stay the source of truth.

Reads usually come from projections: handlers follow the events and keep query-friendly read models up to date, which is why event sourcing pairs naturally with CQRS. Those views lag the log slightly, and since delivery is typically at least once, handlers must be idempotent. Because every event is kept, you can rebuild the state as of any point, or build a new read model from the whole history.

The store can be a purpose-built event store such as KurrentDB, with per-stream reads and an expected-version check on every append for optimistic concurrency, or an append-only table in a general-purpose database. A message broker such as Apache Kafka is not a substitute: it typically lacks per-entity stream reads and optimistic concurrency, though it works well for fanning events out to consumers.