In a CQRS system where the write side uses Event Sourcing, how does a read model — for example, a 'customer order summary' table used by the UI — get built and kept up to date from the event log? Walk through the mechanism end to end.

## What a projection is Once a write model persists state as a stream of events, the read side's whole job is to turn that stream into whatever shape is fastest and simplest for a given query, and it does this through a mechanism usually called a **projection** (or a 'projector' when referring to the running process). A projection is nothing more than a small piece of code that subscribes to events — either the full event stream or a filtered slice of it, such as only events belonging to the `Order` aggregate type — and, for each event it receives, applies a handler function that updates some read-optimized storage. Concretely: - an `OrderPlaced` event handler might insert a new row into an `order_summary` table; - an `ItemAdded` event handler might update a line-items JSON column on that row; - an `OrderShipped` event handler might flip a status column and set a `shipped_at` timestamp. None of this logic runs inside the command path — it's entirely separate code, running in its own process or thread, reading from the event store the same way any other consumer would. ## The load-bearing details The mechanism has a few load-bearing details that are easy to miss. 1. First, projections consume events **in order**, per stream (and often globally too, depending on the guarantee needed), because applying `OrderShipped` before `OrderPlaced` would corrupt the read model. 2. Second, every projector tracks a **checkpoint** — a durable pointer to the last event position it successfully processed — so that if the projector process crashes and restarts, it resumes exactly where it left off instead of reprocessing everything or silently skipping events. 3. Third, and most importantly for why teams adopt this pattern at all, a single event stream can feed an unlimited number of independent projections simultaneously: the same OrderPlaced/ItemAdded/OrderShipped events might simultaneously update a customer-facing order-history table, a warehouse picking-queue table, and a finance revenue rollup, each with a completely different schema, each owned by a different team, none of them aware of or coupled to the others. ## The problem it exists to solve This exists to solve the query problem that a pure event log creates. An append-only log is an excellent write model — full history, no lost updates, natural audit trail — but a poor query model, because answering something as simple as 'list this customer's orders, most recent first' would otherwise require scanning and replaying every event for every order the customer ever placed. Projections pay that replay cost once, incrementally, as events arrive, and store the result in a shape a normal index or SQL query can serve in milliseconds. ## The trade-off The trade-off is consistency and operational surface area. Because the projector runs asynchronously relative to the command handler, there's a real window — typically milliseconds under normal load, but potentially much longer under backpressure or an outage — during which the event exists in the log but hasn't yet been reflected in the read model. Any UI or API that reads from a projection immediately after issuing the command that produced it can observe **stale data**. Handling this well requires deliberate UX or API design. Operationally, every projection is another moving part: - another consumer to monitor for lag; - another checkpoint to persist reliably; - another schema to migrate when query needs change. ## Failure modes in production Failure modes in production tend to cluster around three things: - **projector lag under load** (events pile up faster than the projector can apply them, and the read model falls further behind); - **poison events** (a malformed or unexpected event crashes the projector's handler and, if not isolated, halts the whole projection, silently freezing every read model it feeds); - **drift after a bug fix** (once a projection's handler logic changes, the existing read store reflects the old logic for old data and the new logic only going forward, unless the team rebuilds the store from scratch by replaying the full stream). A well-known real-world pattern here is Marten (a .NET library built on PostgreSQL) or Axon Framework (Java), both of which formalize exactly this projector-plus-checkpoint mechanism as a first-class citizen, letting teams declare a projection and have the framework manage subscription position and rebuild-on-demand.