CQRS

The read copy of the data updates a little after the write copy, through a background sync step. Until that catches up, queries can show old data. That gap in time is called the lag window (or replication lag).

CQRS just means writes and reads use different models. Event Sourcing means you store every change as an event instead of overwriting data. You can do CQRS without Event Sourcing, but when a team does use Event Sourcing, the event log naturally becomes the write side and the read side is built from those events.

A projection is a read-only copy of your data, shaped for easy querying, that's kept updated by watching events from the part of the system that handles writes. Teams build it because the write data is often shaped for correctness, not for fast, flexible reading.

A read model is a copy of your data shaped exactly for what a screen or report needs to show, separate from the data structure used to save changes. It exists so reading is fast and simple, and writing stays focused on correctness.

Reads and writes often need different shapes: writes need consistency and validation, reads need speed and flexible views. Splitting them lets each side be optimized separately — but now you maintain two models instead of one, and they have to be kept in sync.

It loads the relevant object from storage, checks the request makes sense given that object's current state, changes the object, and saves it back, all as one all-or-nothing step touching just one thing, so it can't half-fail.

Before dispatch, check the command's shape is sane - no missing fields, no negative amount. Inside the handler, check things that depend on current data, like whether the account actually has enough money right now.

The UI has to notice the mismatch and fix itself - either roll back to the old value and show an error, or quietly swap in the real value once the read model catches up, so the screen never keeps showing a fact that turned out to be wrong.

Two options: (1) right after saving, read straight from the write side (or a cache of it) for that user's own data instead of the lagging read model; (2) have the client remember a version number from its last write and make the read model wait until it has caught up to at least that version before answering.

The system pulls every past event for that one specific order from the event log, in the order they happened, and feeds them one by one into a fresh, empty Order object, which updates itself a little with each event. By the end, that object looks just like the order does right now, and only then does the command get checked against it.

A separate small piece of code called a projector watches the event log for new events. Whenever it sees an event it cares about (like 'order shipped'), it updates a plain table shaped exactly for what the screen needs to show. The UI only ever reads from that table, never from the raw events.

Idempotent means applying the same event twice gives the same result as applying it once. It's needed because message delivery isn't perfectly exactly-once — retries or crashes can cause the same event to be processed again, and without idempotency that would double-count or corrupt the read data.

Query models copy data into whatever shape a screen needs and duplicate it in several places, so reads are fast lookups instead of expensive joins. The cost is extra storage and the risk that copies can go slightly out of sync with the real data.

A query is only supposed to look at data and return an answer — it should never change anything while doing so. If reading data quietly changes it, you lose the ability to trust that 'just reading' is safe to repeat, retry, or run in parallel.

Now there are two models to deploy, monitor, and fix bugs in, plus a pipeline that keeps them in sync — and if that pipeline breaks or falls behind, the read side can go stale or wrong without anything obviously crashing.

Give each command a unique ID from the client. Before doing the real work, the handler checks whether it has already processed this exact ID - if yes, it just returns the old result instead of charging again.

Use a saga: a sequence of local transactions where each step tells the next one to proceed, coordinated either by a central orchestrator or by services reacting to each other's events. If payment fails after inventory was reserved, the saga runs a compensating action - releasing the reserved inventory - to undo that earlier step.

Saving the change (writing the event) and updating what the screen shows (the read model) are two separate steps done by two separate pieces of code, and the second one takes a little time to catch up after the first. If you check the screen data too fast, you can catch it before it's updated.

You build a brand new copy of the projection from scratch by replaying all the past events into a fresh table, and only switch reads over to it once it's fully caught up — so users keep reading the old (working) version the whole time instead of seeing a half-rebuilt one.

If reads and writes are low-volume and shaped similarly, splitting into two models just adds complexity (sync pipeline, staleness, more code) with no real benefit — you'd push back and ask what specific problem it's meant to solve.

Money is a case where showing the wrong, stale number can cause real harm, letting someone overdraw because the read side hadn't caught up yet. For that one check, read the current true value directly instead of trusting the lagging copy, even if the rest of the app still uses the fast, eventually-consistent read model.

A live subscription gets new events as they happen, like watching a live feed. A catch-up subscription reads through the older, already-happened events first to get up to speed. A projection needs both so it can start from wherever it left off (or from the beginning) and then smoothly switch to real-time.

Either the client makes up the ID itself before sending the command, or the system bends the rule a little and hands back just the new ID, not the full order, as a lightweight acknowledgment.

Measure the gap between when an event was written and when the projector actually applied it (processing lag), plus how many unprocessed events are queued up (offset lag). If the backlog keeps growing, either process events faster with more parallel consumers, or make each projector write cheaper, for example by batching, so it can keep pace.

Use Event Sourcing when you truly need a full history of every change, like an audit trail, or answering 'what did this look like last Tuesday.' If all you need is the current state and maybe a heads-up to other systems when something changes, a normal table that gets updated plus a 'this changed' notification is simpler and usually enough.

Pick the storage technology that matches how the data will actually be queried — fast lookups by ID want a key-value store, full-text search wants a search index, flexible reporting wants a relational table. It's normal to build several different projections from the same events if different features need different query shapes.

Building several different read models (like a search index, a dashboard table, and a fast key-value lookup) all from the same underlying events lets each one be fast for its own job. The cost is you now have several copies of the truth to keep in sync and debug when they disagree.

You test the write side and read side separately, then test the connection between them by writing data, waiting for the read side to catch up (or polling), and checking it matches — instead of one instant check like you would with a single database.

If the app crashes right after saving to the database but before sending the event, the save happened but nobody downstream finds out. The write and the event need to succeed or fail together, not as two separate bets.