Design an Event-Sourcing Store

Design an event-sourcing store: an append-only system of record where every change to a business entity (an aggregate) is persisted as an immutable event, and current state is derived by replaying that entity's events.

Operating context. The store backs a transactional domain such as an order lifecycle. Writes append events to a per-aggregate stream under optimistic concurrency; reads need both fast current-state lookups and full audit history. Expect roughly 20,000 events per second sustained across hundreds of millions of aggregates. Downstream projection builders consume committed events to maintain query-optimized read models, which are eventually consistent.

Out of scope. The domain command logic, the exact projection query API, permanent erasure of immutable events (assume a separate crypto-shredding effort), and the client UI.

What to produce. A high-level architecture covering: the event-stream storage model and its partitioning by aggregate, appending with an expected-version optimistic-concurrency check, snapshotting to bound replay cost on load, how projections / read models are built and kept consistent (and their staleness window), rebuilding a projection from scratch by replay, and idempotent publishing of committed events downstream. Sketch the components and request flow; we will probe specifics at checkpoints.