Optimistic UI
Updating the UI immediately as if a request succeeded, before the server confirms, then rolling back on error. Makes apps feel instant. Requires idempotent mutations and a rollback path. Risky for destructive or hard-to-undo operations.
- Likes, toggles, reordering, edits — fast, reversible actions.
- Apps where perceived latency matters.
- Destructive or irreversible actions.
- When the server may reject often.
Definition
Optimistic UI assumes the mutation will succeed and updates local state immediately, showing the result while the request is in flight. On success, keep it; on error, revert and notify. Often paired with a rollback snapshot.
Why it exists
Waiting for a server round trip feels slow. Optimistic UI hides latency by reflecting the user's intent instantly, which is how local apps feel.
How it works
On a user action, update local state optimistically and fire the request. Keep the previous state for rollback. On success, confirm (maybe reconcile with server truth). On error, revert and show a message. Idempotency makes retries safe.
Scaling limits
Fails for operations that can't be cleanly rolled back (payments, sends). Server-driven state changes can conflict with optimistic state. Out-of-order responses need careful reconciliation.
Cost shape
Free (client logic). The cost is the complexity of rollback and reconciliation.
Alternatives
- Pessimistic (wait for server) — Always correct but feels slow.
- Skeleton/loading state — Honest but doesn't feel instant.
Failure modes
- Rolling back something already partially committed.
- Out-of-order responses corrupting state.
- Optimistic updates on non-idempotent actions.