Lesson 8 of 30

Optimistic Updates and Conflict Resolution

Q: A collaborative to-do list app lets multiple users check off items. Would you make checking off an item an optimistic update? Walk me through your reasoning, including what happens if two users check the same item at nearly the same time.

A strong answer covers: Weighs stakes and reversibility explicitly rather than defaulting to 'always optimistic' or 'always pessimistic'; Concludes optimism is reasonable here given the low stakes and easy reversibility of a checkbox toggle; Names a concrete, honest simplification for the concurrent-edit case (e.g. last-write-wins, or refetch-and-reconcile) rather than claiming a fully general conflict-resolution solution; Describes a clear, visible failure path if the server ultimately rejects the change, rather than a silent revert.

Applying a mutation's expected result to the UI before the server confirms it makes an app feel instant — but only if failure and conflict are handled as first-class design questions, not afterthoughts.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

Which action is the stronger candidate for a fully optimistic UI update?

Submitting a payment, since showing 'success' immediately makes checkout feel fasterLiking a post, since a failed like is low-stakes and easy to visibly revertBoth are equally good candidates, since optimism is a blanket rule that should apply consistently across an app

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Optimistic Updates and Conflict Resolution

What interviewers actually ask about this, and what a strong answer has to cover.

A collaborative to-do list app lets multiple users check off items. Would you make checking off an item an optimistic update? Walk me through your reasoning, including what happens if two users check the same item at nearly the same time.

A strong answer covers

Weighs stakes and reversibility explicitly rather than defaulting to 'always optimistic' or 'always pessimistic'
Concludes optimism is reasonable here given the low stakes and easy reversibility of a checkbox toggle
Names a concrete, honest simplification for the concurrent-edit case (e.g. last-write-wins, or refetch-and-reconcile) rather than claiming a fully general conflict-resolution solution
Describes a clear, visible failure path if the server ultimately rejects the change, rather than a silent revert

Likely follow-ups

What would change about your answer if this were a shared bank balance instead of a to-do checkbox?
If you chose last-write-wins, what's the actual user-visible consequence when two people's optimistic updates race each other?

Practice these with the AI interviewer →

The plain-language idea

An optimistic update applies a mutation's expected result to the UI immediately, before the server has actually confirmed anything happened. A "like" button fills in the moment it's tapped; a posted comment appears in the list right away. The real network round-trip might take a few hundred milliseconds, but the user never sees that wait — the app feels instant.

That speed is bought with real complexity, and a strong design answer treats both halves of it as first-class:

What happens on failure. If the server actually rejects the mutation, the optimistic change has to be rolled back to the previous state, and the user needs a clear signal that their action didn't actually succeed. Silently reverting with no explanation is a real, common UX bug — the user is left confused about whether their like registered or not.
What happens with concurrent or out-of-order updates. Two rapid edits to the same resource, or a stale optimistic state getting overwritten by a real server response that arrives out of order, is genuinely hard to resolve with full rigor. Most real apps don't try to solve it perfectly — they accept a simplified strategy like last-write-wins, or simply re-fetching the authoritative state and reconciling against it.

See it in a real thing: a "like" button versus a payment button

Tapping "like" on a post is a textbook case for optimism: the action is low-stakes, instantly and cheaply reversible, and the failure mode (a like doesn't actually register) is minor and easy to signal. The button fills in immediately; if the server later rejects it, unfilling it and showing a small "couldn't save" toast is a completely acceptable failure story.

Submitting a payment is the opposite case. Showing "payment successful" before the server has actually confirmed the charge is a serious correctness risk — if it fails, the user has already been told something false, possibly acted on that false belief (closed the tab, told someone else), and unwinding that is far worse than a brief loading spinner would have been. The right design here is the plain, honest one: show a pending state, wait for real confirmation, then show success or failure based on what actually happened.

What people usually miss

Watch out

Optimistic updates without a defined failure path are worse than no optimism at all — a UI that silently reverts, with no explanation, leaves the user unsure whether their action worked, which erodes trust more than a slightly slower confirmed update would have.
Conflict resolution is genuinely hard, and claiming a fully general solution is a red flag, not a strength. Naming a concrete, honest simplification (last-write-wins, or refetch-and-reconcile) and explaining why it's acceptable for this specific feature is the stronger interview answer.
The decision isn't binary per app, it's per action. The same app can reasonably use optimistic updates for a like button and a strictly pessimistic (wait-for-confirmation) flow for checkout — this is a per-feature judgment call, not a global architectural stance.
Destructive actions (delete) deserve extra scrutiny even when they seem "reversible" via undo — an optimistic delete with no undo window, that later fails to actually delete on the server, can leave a confusing "it's back" surprise if not handled deliberately.

Why this matters in interviews

"Would you use an optimistic update here, and what happens if it fails?" tests real judgment, not just implementation knowledge — the strongest answers explicitly weigh stakes and reversibility per action rather than treating optimism as a blanket rule to apply everywhere or nowhere.