Problem statement
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.
Requirements
This assessment is a Premium feature.
The statement above is free to read. The functional and non-functional requirements, and the graded canvas that scores your design against them, come with Premium.
Topics
- System Design HLD
- Data Event-Sourcing
- Data Append-Log
- Patterns Cqrs
- Data Partitioning