Queues, Streams, Eventing
Eventual-consistency UX: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the material stick.
Reconstruct the unit’s core ideas — the consistency window, optimistic UI’s three-part contract, when to show a pending state, idempotent retries, and deliberate conflict resolution — without looking back at the lesson.
- 01What is the consistency window, and why does an async backend make it the frontend's problem?
- 02State the three-part contract of optimistic UI, and which part juniors skip.
- 03When is optimistic UI the wrong tool, and what do you show instead?
- 04Why does every pending state need a timeout, and what are the two failure modes that lurk here?
- 05Explain the LWW vs merge vs CRDT tradeoff for reconciling two concurrent async writes, and the frontend's job in each case.
- 06Why does 'POST then immediately refetch' break read-your-own-writes, and how do you keep the eventual refresh without the violation?
If you could reconstruct each answer from memory, you hold the unit’s spine: an async write moves the consistency window onto the frontend; optimistic UI’s apply-send-reconcile contract buys ~0ms perceived latency but is a lie without the rollback step; when the server owns the outcome you show an honest pending state guarded by a timeout; double-submits are made safe with an idempotency key; concurrent writes are reconciled deliberately (LWW for simple fields, CRDTs for shared text); and read-your-own-writes survives by echoing locally instead of trusting a racing refetch.