Rollback on Error and Conflict Resolution

Rolling back an optimistic add (remove the item) or delete (restore the item) is straightforward. Rolling back an update is more complex: you must restore the exact previous value. If the item was updated multiple times optimistically, you must track each prior value separately, not just the original server state.

Consider this scenario: the server has item at value Z. You optimistically update to X. While your request is in-flight, another user updates the same item to Y on the server. Your request arrives and the server rejects it (conflict). Your rollback target is Z, but the server's current state is Y. Restoring Z would overwrite Y incorrectly.

The safest rollback strategy for updates is to refetch the item from the server on any mutation error rather than restoring a locally-captured snapshot. This guarantees you display the authoritative server state, regardless of what other users may have changed concurrently. Refetch is slower but always correct.

A well-designed API returns HTTP 409 Conflict when an optimistic update fails due to a concurrent modification. The response body typically includes the current server state. Your error handler should detect 409, use the response body to update your local state with the server's current value, and notify the user that their changes were not saved.

An idempotent mutation produces the same result when applied multiple times. Designing mutations to be idempotent (using PUT instead of POST, including the full resource state, using idempotency keys) makes it safe to retry on failure without risk of double-applying the change. This simplifies rollback logic significantly.

Double-clicks on a submit button can fire two identical mutations. Prevent this with an isSubmitting flag: set it to true when mutation starts, reset it when complete (whether success or failure). Disable the trigger element when isSubmitting is true. This eliminates duplicate mutations at the UI level.

For server-side deduplication, include a unique Idempotency-Key header with each mutation request. Generate it with crypto.randomUUID() when the user initiates the action. The server detects duplicate keys and returns the same response as the original request without re-applying the operation.

While a mutation is in-flight, you can show a subtle indicator that the optimistic state is unconfirmed: a small pulsing dot, a "Saving..." text, or a reduced opacity on the item. This communicates uncertainty without blocking interaction. Clear the indicator on success or rollback on failure.

Unexpected errors in rollback logic (e.g., accessing properties of undefined during state restoration) can crash the component. Wrap mutation-heavy components in an error boundary so that catastrophic rollback failures show a graceful error UI instead of a blank screen. Log these errors for debugging.

A reliable conflict detection strategy: include a version number or ETag with every mutation. The server compares the client-sent version with its current version. If they differ (another update occurred), it returns 409. This is optimistic concurrency control — you assume no conflict but detect it when it occurs.

Rollback logic is often untested because network failures are hard to simulate. Use tools like Mock Service Worker (MSW) to return error responses in tests. Write explicit tests for: 409 Conflict handling, network timeout rollback, double-click deduplication, and state consistency after failure. These edge cases are where bugs hide.

Which HTTP status code does a well-designed API return when an optimistic update fails due to a concurrent modification by another user?

Update rollback is more complex than add/delete — always refetch on error to avoid stale snapshot issues. HTTP 409 Conflict signals optimistic concurrency failures; use the response body to restore the server's current state. Design mutations to be idempotent for safe retries. Prevent double-fires with isSubmitting and server-side idempotency keys. Test rollback paths explicitly using MSW to simulate errors.