TL;DR / Optimistic UI immediately reflects the predicted outcome of a user action in the interface before the server confirms it, rolling back to the previous state if the server rejects the change.
How It Works
┌──────────┐ ┌────────────┐ ┌────────────┐
│ User │ │ Optimistic │ │ Server │
│ Action │───────→│ UI update │───────→│ request │
└──────────┘ └────────────┘ └────────────┘
200 OK │
┌───────│ Error
│ └──────┐
│ │
│ │
│ ↓
┌───────────┐│ ┌──────────┐
│ Confirm │↑ │ Rollback │
└───────────┘ └──────────┘
Every network request introduces latency. On a 3G connection, a simple POST takes 300-800ms. On a fast connection, it is still 50-150ms. During that time, the UI either shows nothing (the user wonders if their click registered), shows a spinner (acceptable but not great), or shows the expected result immediately (optimistic update). The third option provides the best perceived performance, but it introduces a fundamental problem: what happens when the server says no?
The Optimistic Update Pattern
The pattern has three phases. First, when the user takes an action (likes a post, deletes an item, submits a form), the UI immediately updates to reflect the expected outcome. The like count increments, the item disappears, the form shows a success message. This happens synchronously, before any network request completes.
Second, the actual request is sent to the server in the background. The UI is already showing the expected state, so the user perceives zero latency.
Third, when the server responds, one of two things happens: success confirms the optimistic update and no visual change is needed, or failure triggers a rollback that reverts the UI to its pre-action state, typically accompanied by an error message explaining what went wrong.
Snapshot-Based Rollback
The simplest rollback strategy captures a snapshot of the relevant state before applying the optimistic update. If the server rejects the change, restore the snapshot. This works well for isolated state changes -- toggling a like, deleting a single item, updating a single field.
The implementation stores the previous state alongside the optimistic state. In React, this might be a ref holding the pre-update state, or a state library feature (TanStack Query's onMutate returns a context object that onError receives for rollback). The critical requirement: the snapshot must be captured before the optimistic update is applied, not after.
Queue-Based Rollback
For complex operations with multiple dependent changes, a queue of pending optimistic updates is more robust. Each entry in the queue contains the action, the optimistic state diff, and enough information to reverse it. When the server confirms, the entry is removed from the queue. When the server rejects, the entry's reversal is applied.
If multiple optimistic updates are in-flight simultaneously (user likes three posts in quick succession), queue-based rollback handles partial failures correctly. If the second like fails, only that like is rolled back, while the first and third remain. Snapshot-based rollback struggles here because reverting to a snapshot from before the first like would also undo the first and third likes.
Conflict Resolution
Optimistic updates can conflict with server-side state that has changed since the client's last sync. The user deletes an item, but another user has already modified it. The server rejects the delete. The rollback restores the item, but should it restore the original version or the modified version?
The safest approach: on rollback, re-fetch the authoritative server state rather than restoring the client snapshot. The snapshot may be stale if other real-time updates arrived while the optimistic change was in-flight. TanStack Query's invalidateQueries pattern does this automatically -- a failed mutation triggers a refetch of the affected query, ensuring the UI shows the true server state.
Error Communication
Rollbacks must be visible to the user. A silent rollback (the like count quietly decrements back) confuses users who think their action succeeded. Show a toast or inline error explaining the failure, animate the rollback so the user sees the change reversing, and provide a retry action.
Framework Support
TanStack Query provides first-class support through mutation options: onMutate applies the optimistic update and returns rollback context, onError receives that context and rolls back, onSettled refetches to ensure consistency.
React 19's useOptimistic hook creates a layer of optimistic state that automatically resolves when the associated server action completes. If the action fails, the optimistic state is discarded and the component re-renders with the original state.
Gotchas
- Race conditions between optimistic updates and real-time sync can cause flicker: the optimistic update shows the new state, a real-time push delivers the old state (from before the server processed the update), then the mutation response confirms the new state. Debounce or suppress real-time updates for resources with pending mutations.
- Rollback of accumulated optimistic updates (multiple changes to the same entity) requires careful ordering. Rolling back to the wrong snapshot causes data loss.
- Animations during rollback must reverse smoothly. If the item exit animation completed but the delete failed, the item must animate back in, not just appear.
- Server validation that the client cannot replicate (uniqueness constraints, rate limits, permission checks) makes optimistic updates risky for those operations. Only apply optimistic updates when the client can predict the server's response with high confidence.
- Offline queues with optimistic UI complicate rollback further because the server response may arrive minutes or hours later. The user may have navigated away, and the rollback context is lost.