Skip to content

CONCEPT Cited by 3 sources

Optimistic Update

Definition

An optimistic update is a client-side UI technique where the application applies the effect of a user action to local state immediately — before the backend confirms it — so the interface feels instant. When the server responds, the client reconciles: on success it settles the provisional state (or replaces it with the authoritative value); on failure it rolls back and typically surfaces an error. The bet is that most operations succeed, so paying the round-trip latency up front on every action is a worse experience than occasionally undoing a rare failure.

"We insert the user message to the dataset to show it instantly. We call this an optimistic update." (Source: sources/2026-09-29-yelp-the-making-of-the-yelp-assistant-ui)

Distinguish this from optimistic concurrency control (a storage/transaction technique that detects write conflicts via version checks). Optimistic update is about UI responsiveness; optimistic locking is about conflict detection. They share the name and the "assume success, verify later" philosophy but operate at different layers.

The lifecycle

  1. Apply locally — mutate the client's view/state store to reflect the intended outcome the instant the user acts.
  2. Send to backend — fire the actual request in parallel.
  3. Reconcile on response:
  4. Success → settle the provisional state; often replace it with the server's authoritative representation.
  5. Failure → roll back the local mutation and communicate the failure (retry prompt, error message, disabled input).

Worked example: a turn-based chat (Yelp Assistant)

Yelp Assistant's chat loop is the canonical instance. On Send, the client optimistically inserts both the user message and a typing indicator into its local dataset — the user sees their bubble and a "bot is typing" state instantly, with no network wait. "The client is fully responsible for inserting and removing the typing indicator at the right time." When the bot replies, the client removes the typing indicator and inserts the bot_message; on failure it removes the typing indicator and inserts an error message (recoverable → retry, non-recoverable → end session). The typing indicator is ephemeral provisional state; the user message is persistent provisional state that the successful response confirms. (Source: sources/2026-09-29-yelp-the-making-of-the-yelp-assistant-ui)

Reconciliation under read-after-write lag

A subtlety appears when the backend is eventually consistent: a write can be accepted before the read model reflects it, so naively clearing the optimistic overlay on write-ack makes the UI appear to undo the action until the read catches up. Atlassian's event PWA solved this with an explicit intermediate state: "The PWA saves an operation locally before contacting the backend, performs an optimistic update, changes it to settled after the backend accepts it, and removes that overlay only when a live Jira read reflects the operation. The extra settled state avoids the UI appearing to undo an action during read-after-write lag." (Source: sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack). This makes optimistic update a companion technique to eventual consistency: the overlay bridges the gap between write-acknowledgement and read-model convergence.

Interaction with real-time / collaborative systems

In real-time collaborative products the optimistic overlay must coexist with concurrent updates streaming in from other clients. Figma's real-time data layer "applies optimistic updates across the product, even for unrelated" changes, meaning the client-side merge of provisional local mutations against server-pushed authoritative state is a first-class concern of the data layer, not a per-feature hack (Source: sources/2026-04-21-figma-keeping-it-100x-with-real-time-data-at-scale; see also LiveGraph).

Tradeoffs

  • Pro: perceived latency drops to near-zero on the common (success) path; the UI feels responsive even over slow or high-latency links; pairs naturally with offline-first designs where the write may be deferred entirely.
  • Con: you must implement rollback (harder than it looks when an action has ripple effects); under eventual consistency you need an explicit settled / reconciliation state to avoid flicker or apparent undo; on failure the user sees state "disappear," so the error UX must be clear; the client now holds provisional truth that can diverge from the server, so graceful degradation on the failure path is mandatory.

Seen in

Last updated · 766 distilled / 2,225 read