What is optimistic UI execution and why is perceived latency different from actual latency?
Optimistic UI applies a mutation to local state immediately and awaits server confirmation in the background. Perceived latency is instant (user sees the change right away), while actual latency is the round-trip time. Request-response UIs block and show a spinner, making both latencies the same. Optimistic UI trades accuracy risk (the server might reject) for responsiveness.
Answered in
Optimistic UI: The Illusion of InstantApply mutations locally and reconcile in the background, collapsing perceived latency from 150 ms to instant. Rollback, idempotency keys, offline queues.
Read the full analysisOther questions this article answers
- How does rollback work when the server rejects an optimistic mutation?
- What is an idempotency key and why does it prevent double-charging or duplicate inserts?
- How do you handle ordering when mutations are queued offline and replayed later?
- When is optimistic UI the wrong call and what should you use instead?
More system design questions
- Why doesn't Google just run Dijkstra faster?
- What is a shortcut edge and when is it precomputed?
- How much space do shortcut edges take compared to the original graph?
- Can Contraction Hierarchies handle dynamic graphs like traffic or road closure?
- Why contract low-degree nodes first instead of high-degree ones?
- What is a CRDT and why does it matter for real-time collaboration?
- How do CRDTs handle concurrent edits without a central server referee?
- Why did Figma move from operational transforms to CRDTs?
Every answer on Crashtech is written by the editor of the article it comes from — never auto-summarised. Browse all answers or the System Design beat.