Queues, Streams, Eventing
Eventual-consistency UX: multiple-choice review
Six questions that cut across the whole unit. Each one mirrors a UX decision you make over a real async backend — not a definition to recite, but a tradeoff to weigh while the consistency window stretches under load.
Confirm you can connect the consistency window, optimistic UI, read-your-own-writes, honest pending states, idempotent retries, and conflict resolution — the synthesis the lesson built toward.
A POST drops work on a queue and returns 202 Accepted in 40ms; a consumer writes the row ~700ms later. The UI POSTs then immediately refetches the list. What does the user see, and why?
You are wiring an optimistic update in TanStack Query useMutation. Which step do juniors most often skip, and what breaks without it?
A 'Pay' button shows a spinner. The event confirming the charge never arrives because the consumer crashed. With no extra handling, what happens?
A predictable action (toggle a checkbox that goes through a queue, consumer writes ~500ms later) is shown with a blocking spinner until the consumer confirms. What is wrong with this UX choice?
Two users edit the same shared document body concurrently; both writes go through a queue. The backend resolves with last-write-wins (LWW). What is the senior critique?
A user clicks 'Submit', sees no feedback because the pending state was never built, and clicks again. Two messages land on the queue. What is the durable root-cause fix?
Across the unit the through-line is one rule: an async write is not instantly readable, so the consistency window becomes the frontend’s problem. When the client can predict the result, use optimistic UI — snapshot, predict, reconcile or roll back — to buy ~0ms perceived latency against the 100ms/1s/10s thresholds. When the server owns the outcome, show an honest pending state with a timeout so a never-arriving event cannot spin forever, and never collapse a 202 into a success toast. Echo writes locally instead of trusting a racing refetch, key retries so a double-click cannot double-charge, and resolve conflicts deliberately — LWW for simple fields, CRDTs for shared text — making the outcome legible rather than silently overwriting the user.