Design an Event-Sourced System with CQRS

Data, Storage & ConsistencyHarddesign-event-sourcing-cqrs

Design an Event-Sourced System with CQRS

Design a system whose source of truth is an append-only event log, with read models projected from it — and work out what that costs when a projection is wrong.

Event SourcingCQRSMaterialized ViewsSnapshotsReplay

Traffic & Capacity Estimates:

500M events/day · 40 read projections · full replay of 5 years within 6 hours

Functional Requirements

•Append immutable domain events to a per-aggregate stream with optimistic concurrency on version.
•Rebuild current state by folding events, using periodic snapshots to bound the read cost.
•Project events into purpose-built read models (SQL views, search indexes, caches).
•Replay the log to rebuild any projection from scratch after a bug or a schema change.

Non-Functional Requirements

•Command handling p99 under 50ms including the append.
•Read models converge within 2 seconds of the originating write in steady state.
•Event schema must evolve without invalidating years of already-written events.

Back-of-the-Envelope Math

500M events/day * 400 bytes = 200 GB/day, ~365 TB over 5 years before compaction.
A snapshot every 100 events caps aggregate rehydration at 100 event applications.

Key Architectural Trade-offs

CQRS buys independently scalable, purpose-shaped reads and hands you eventual consistency in the UI — the write that just succeeded isn't in the list yet.
Events are immutable, which makes auditing free and schema migration permanent work: upcasters, versioned event types, and no 'just alter the table'.
Full event sourcing vs an ordinary state store plus a change log — most systems need the audit trail, not the rebuild-anything property.

Click or drag a component onto the canvas, then connect the handles to draw the data flow.

3 nodes · 2 edges

Components · 35

Client & Edge4

Compute & Gateway7

Storage & Caching11

Messaging & Streaming6

Coordination & Ops5

Intelligence2

React Flow