Optimistic Update Reconciliation

Optimistic updates apply a change locally and immediately, then send it to the server. The interaction feels instant, which is the entire point.

The difficulty is the case where the server's response differs from what was shown: a validation failure, a concurrent edit, a permission change, a stale precondition. The user has already seen their change, and now something must happen.

The three options and their costs

• Roll back. Correct and jarring — the user watches their work disappear, usually with no explanation of why. Acceptable for small independent actions, poor for anything the user invested effort in.
• Keep local and retry. Good for transient failures, dangerous for genuine conflicts, because the retry may eventually overwrite someone else's work.
• Surface the conflict for the user to resolve. Most correct for genuine conflicting intent, and the most interface work — which is why it is usually skipped and why systems silently lose edits.

The policy must be chosen per operation type. A "like" can roll back silently; a paragraph of typed text must not.

Implementation patterns

• A queue of pending operations, applied optimistically, retried on reconnection, with each carrying enough context to be reapplied or reversed.
• Idempotency keys on mutations, so a retry after an ambiguous failure does not create a duplicate — the client cannot distinguish "not received" from "received, response lost".
• A merge strategy matched to the data shape: CRDTs for collaborative text, last-write-wins for independent scalar fields, explicit resolution where intent genuinely conflicts.
• Document state kept separate from server cache, because a cache entry can be discarded when stale and one containing unsaved user edits cannot. Conflating them is what makes offline support and cache invalidation fight each other.
• Visible sync status. Users tolerate offline editing; they do not tolerate uncertainty about whether their work is saved. The status indicator is a core feature, not an affordance.

Industry example

Collaborative document and note-taking products converge on the same lesson: the merge algorithm is the part that gets the attention and the reconciliation policy is the part that generates the support tickets. A technically correct convergence that relocates the object a user is currently dragging, or that silently drops a paragraph typed while offline, is experienced as data loss regardless of its formal properties.

The design rule that follows is that user-authored content is never discarded silently — it may be rejected, flagged, or surfaced for resolution, but it is not removed without the user knowing.

Failure scenarios

• Silent rollback of typed content, which users experience and report as data loss.
• Blind retry into a conflict, overwriting a collaborator's work.
• No idempotency key, producing duplicates on retry.
• One policy for all operations, wrong for either the trivial or the important ones.
• No sync indicator, so users cannot tell whether closing the tab is safe.

Trade-offs

Optimistic updates trade correctness-at-the-moment for perceived speed, and the trade is almost always worth making for user-initiated actions with a high success rate. It is a poor trade where failures are common or where showing an unconfirmed state is misleading — a payment confirmation, an inventory reservation, a permission grant.

The test is what the user would do differently if the optimistic state turns out to be wrong. If the answer is "nothing", be optimistic. If they would act on it irreversibly, wait for confirmation.

Interview question

"A user types a paragraph while offline. When they reconnect, the server rejects the edit because someone else changed the same section. What should happen, and what would you never do?"