CQRS & Event Sourcing

These two patterns are frequently mentioned together, and they compose well, but they solve different problems - CQRS is about separating how you write from how you read; event sourcing is about how you actually store state in the first place. This chapter builds on the CQRS and event-sourcing chapters from LLD Fundamentals' schema-design track, applied here to API and service design specifically.

Command Query Responsibility Segregation splits an API's write path (commands - mutations that change state) from its read path (queries - fetching data), letting each be optimized independently. A write model might be normalized and transaction-safe; a read model might be a heavily denormalized, pre-joined view optimized for exactly the queries clients actually make - the same write-optimized-versus-read-optimized trade-off from LLD Fundamentals' schema chapter, but expressed here as two separate API surfaces (or even two separate services) instead of two database schemas.

Instead of storing only the current state and overwriting it on every change, event sourcing stores every state-changing event, and current state is derived by replaying them - this preserves complete history for free (exactly the append-only ledger technique from LLD Fundamentals' financial-modeling chapter) and lets the same event log support multiple different read models built by replaying events differently, which is exactly where event sourcing and CQRS compose naturally: the write side appends events, and one or more independently-optimized read models are built (and rebuilt, if needed) by replaying that same event log.

Because the read model is built from events asynchronously, a client that just issued a command (write) and immediately queries the read model might not see its own change reflected yet - a real API design decision, not just an implementation detail. Options include: accept the eventual-consistency window and design the client experience around it (optimistic UI updates, for instance), or offer a way for a client to read its own writes immediately (routing that specific read back through the write model, or returning enough data in the command's own response that a follow-up read isn't needed right away).