Event Store Design

The event store is the append-only log at the center of event-sourced systems. Events are written once and never modified. This immutability is not a constraint — it is the guarantee that the history is trustworthy. If events can be edited, the audit trail is worthless. If events can be deleted, the state reconstruction is unreliable. The append-only contract is the foundation.

1. Stream Organization Events are grouped into streams — typically one stream per aggregate. The OrderStream for order-123 contains every event that happened to that order: OrderPlaced, PaymentReceived, ItemShipped, OrderCompleted. Stream-per-aggregate gives you isolated replay and optimistic concurrency at the aggregate level without global coordination.
2. Schema Versioning Events are forever. The schema you publish today will be read years from now. Version every event schema from day one. Use upcasters — functions that transform old event formats into the current schema at read time — so consumers always see the latest structure without rewriting the store. An event store without schema versioning is a ticking migration bomb.
3. Snapshot Strategy Replaying thousands of events to derive state is slow. Snapshots — periodic materialization of aggregate state — provide a checkpoint. Replay starts from the latest snapshot instead of event zero. Snapshot frequency is a tuning parameter: too frequent wastes storage, too infrequent wastes compute. Measure replay latency and adjust.