Optimistic updates · FE/BE contract · Rollback paths

Optimistic UI

Like a post under varying latency and failure rates. Toggle optimistic vs pessimistic; watch the rollback flicker and the queued wait.

Optimistic UI lies to the user, kindly. The local state updates the moment they click; the server gets told later, and on the rare day the server says no, the lie has to be undone. This simulator runs a like button against a fake server you control — latency slider, failure-rate slider — and surfaces what feels different. Flip to pessimistic mode and the heart waits for the round trip; flip back to optimistic and it fires instantly, with the rollback path doing quiet work behind the scenes. The stats panel shows perceived latency and rollback counts diverging in real time. The whole point: optimism feels faster, but ships more code.

Latency600 ms

Server failure rate20%

@dura · 2h

The hardest part of optimistic UI isn’t the optimism — it’s the path back when the server says no.

UI updates instantly

optimisticactive

Clicks issued: 0
Server confirms: 0
Rollbacks: 0
Avg perceived latency: —

pessimistic

Clicks issued: 0
Server confirms: 0
Rollbacks: 0
Avg perceived latency: —

Request queue

no requests yet

Click the heart. Each request shows up here while it’s in flight, then settles or fails.

Felt the trade?

See at least one rollback in optimistic mode(0/1)
Click at least three times in pessimistic mode(0/3)

Explore the activity to earn its passport stamp. Stamps record exploration, not mastery.

What’s happening under the hood

›Perceived latency vs complexity: optimistic mode collapses time-to-feedback to a single frame (~16ms) at the cost of a reconcile path that must exist, must be tested, and must handle the case where the user kept interacting before the server got back to you. Pessimistic mode pays a real round trip every click, and stops a class of bugs from being possible at all. There is no free choice — the trade is between user-felt speed and code surface area.
›Rollback-path-exists invariant: every optimistic update in production must have a corresponding revert. The simulator makes the rollback visible as a flicker because real codebases hide it behind a toast — and the day the rollback path is missing or wrong is the day users see counts that disagree across refreshes. Idempotency keys (so retries don't double-apply) and version numbers (so a late-arriving response can't overwrite a newer one) are how real systems make the rollback safe; the rapid-click burst in this demo is the closest thing to seeing why both are necessary.
›Irreversible-ops boundary: never go optimistic for payments, deletes, account changes, or any action whose rollback can't be made truly invisible. The cost of a wrong rollback on a like is a flicker; the cost on a charge is a refund ticket and a furious user. The rule of thumb: optimistic for actions the user repeats freely and won't notice a 200ms hiccup on; pessimistic for actions where being wrong has a tail.

Dig deeper

Phase 4 · Backend Engineering

The concept you just explored is taught with full depth in the formal DURA curriculum.