Split the write model from the read model (CQRS) and store state as a log of events instead of current values (event sourcing).
Send a command (write), then a query (read). Two separate models.
CQRS splits writes and reads into separate models. The write side enforces rules; a projection keeps a read side shaped for fast queries. Each scales on its own, at the cost of complexity and a brief lag before the read model catches up.
Plain English: CQRS means using one model/datastore optimized for writes and a separate one optimized for reads, instead of forcing both through one schema. Event sourcing means storing every change as an event ('deposited $50') and computing current state by replaying them, instead of just storing the latest balance. Powerful, but a lot of complexity.
Two related but separable patterns. CQRS (Command Query Responsibility Segregation) splits the system into a write side (commands that change state) and a read side (queries), each with its own model and often its own datastore. Event Sourcing stores state as an append-only log of immutable events; current state is derived by replaying those events, rather than by storing and overwriting the latest value.
A single model optimized for both writes and reads compromises on both: normalized for write integrity but slow for complex reads, or denormalized for reads but awkward to update. CQRS lets each side be optimal independently. Event sourcing solves loss of history: a conventional table stores only the current value, throwing away how it got there, while event sourcing keeps the full audit trail, enables temporal queries ('what was the balance on March 1?'), and lets you rebuild read models by replaying events.
CQRS: commands go to the write model (often normalized, transactional); the write side emits events; one or more read models (denormalized, query-optimized, possibly in different stores) are updated from those events asynchronously. Reads hit the read models. Event sourcing: every state change is appended as an event to an event store. Current state = fold over the event stream. Snapshots periodically checkpoint state so you don't replay from the beginning every time. The two combine naturally, since event sourcing's event stream feeds CQRS read models, but each can be used without the other.
The ledger is naturally event-sourced: append immutable debit/credit entries and derive balances; you never overwrite, giving a perfect audit trail
An append-only event log of orders/trades is the source of truth; the in-memory order book is a read model rebuilt by replaying events on restart
The per-document operation log is event sourcing: document state is snapshot plus replayed deltas, the read model for editors
CQRS comes up when an interviewer asks how you'd design a system with very different read and write requirements, like a social feed with few writes but millions of reads per post. The key insight is that CQRS lets you optimize each path independently, with a separate denormalized read store. You don't have to pair it with event sourcing, so clarify that distinction. Candidates lose points by treating CQRS as an all-or-nothing pattern or by conflating it with event sourcing when the interviewer only asked about read-write separation.