Checkpoint: Collaborative & Replicated State

The loop lesson ended with a bill: four very different apps, each demanding its strategy. Here they are, plus six more rooms where this section's judgment gets spent for real.

Five lessons ago, two answers meant catastrophe. Since then: the conflict became a receipt, values learned to merge themselves, operations learned to move, the shelf got price tags, and a pocket-sized loop learned to run all of it through tunnels and dead batteries. The exam below never asks for a definition. It hands you an app, a review, or an incident, and asks what you buy.

One compression before the exam. Every lesson here is the same law in a different costume:

Two answers are a purchase, not a failure. Merge what composes, transform what sequences, refuse what contradicts — and whatever resolves must converge: deterministic, order-blind, counted once.

• The Conflict Problem: the receipt and the contract. A conflict is proof you stayed available; the divergence trap waits for any resolver that isn't order-blind — and last-write-wins passes the contract while failing the intent, so convergence is the floor, not the finish.
• CRDTs: the shape carries the merge. Any order, any grouping, any repeats; slots, tags, and tombstones on the bill — and at the border, converged is not correct.
• Operational Transformation: coordinates rot, intent doesn't. Rewrite the operation as if the other had already happened; one server's order made it provable, and the graveyard shows what happens without one.
• Conflict Resolution Strategies: seven tools, each priced by what it spends. A default is not a decision, and the choice is per field, never per system.
• Offline-First Sync: the loop is the product. Unacked is applied-or-lost, so re-send everything and count everything once — and collaboration is this same loop with the offline shrunk to milliseconds.

The exam hands you situations and asks which costume the law is wearing.

Four of the questions hand you an app and make you shop, so here is the whole discipline, compressed to what fits in a design review's margin:

One: could both answers be true? If not — one seat, one username, one floor on the stock — leave the merge shelf. Refuse, coordinate through the one-answer door, or park both versions for a human.

Two: what shape is the field? A snapshot earns last-write-wins honestly. A count, set, or flag that must stay exact is CRDT country. A sequence — text, anything where position is meaning — is the text lane: transforms behind your server, character identities offline. An accumulation whose meaning only the app knows: siblings merged at read, or union with the resurrection price accepted out loud.

Three: re-take the two-question exam. Does it converge on every replica? Does what people meant survive? And one promotion from the loop lesson: if the operation has effects — money moved, mail sent — convergence laws don't cover it; idempotency keys do.

Walk it per field, not per system. One object can honestly carry a last-write-wins photo, a CRDT counter, and a refused seat.

Ten scenarios from the rooms where this section earns its keep: four product designs, an architecture review, a flash-sale incident, a startup pitch, and one apology to a user who lost a note. Every wrong option is a real wrong turn these five lessons taught you to refuse. Pass is seven of ten; miss one and the verdict names the exact lesson to revisit.

If this section landed, here is the capability it certifies.

In a design review, you can hear "users edit the same record from two devices" and respond with questions instead of fear: could both answers be true, what shape is each field, who can judge a merge. You can put a price on every strategy someone proposes, and you can spot the field that quietly needs the one-answer door before it becomes a double-sold seat.

In an incident, you can read a resurrected cart item and name union's price; read a minus-one counter and know the type worked while the invariant didn't; read a double charge and find the missing idempotency key in minutes.

And when someone asks the interview classic — design Google Docs — you can answer with the real architecture: a local-first loop, an ordering server, transformed operations in the converge slot, and honest sync state in the UI. That vocabulary — the receipt, the contract, the shapes, the shelf, the loop — is assumed from here on.

• The law: two answers are a purchase. Merge what composes, transform what sequences, refuse what contradicts — converge deterministic, order-blind, counted once. Five lessons, one sentence.
• The five costumes, one line each: the conflict is a receipt and the contract has three laws · the shape can carry the merge, but converged is not correct · coordinates rot, so transform the operations behind one order · seven tools, priced, chosen per field — a default is not a decision · the loop is the product, and unacked means re-send, deduped by id.
• The sixty-second read: both true? what shape? converge and intent? Then keys for effects, and walk it per field.
• Passing means permission. Seven of ten says the judgment is yours, and everything ahead assumes it.

Now notice what every lesson in this section quietly assumed: that requests eventually return. The sync retries, the pulls, the pushed operations — all of them wait on something, and this course has never yet asked the operational question: wait how long, decided by whom, and what happens to a fleet when ten thousand waits stack up on one slow dependency? That's the next section's opening move — time as a budget, spent deliberately down a call chain: Timeout Hierarchies.