When is optimistic UI the wrong call and what should you use instead?
Avoid optimistic UI for payments (charge failures are irreversible), hard deletes (no undo), and any action with complex server-side validation that can fail unpredictably. Use request-response with clear feedback for these. Also skip it if the operation has race conditions (e.g., a shared counter) where the server's state is authoritative and changing rapidly.
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
- What is optimistic UI execution and why is perceived latency different from actual latency?
- 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?
More system design questions
- Why does an index's internal data structure matter if it all ends up 'faster than a scan'?
- Why is disk I/O the thing index structures are actually optimizing for?
- Why can't a hash index handle range queries?
- What makes a bitmap index different from a B-tree, and when is it better?
- Why do B-trees stay balanced automatically as data is inserted?
- Why does a database need an index at all — why can't it just scan the table?
- When is a hash index better than a B-tree index?
- What is a composite index and why does column order matter?
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.