Optimistic UI needs a rollback plan
Updating the screen before the server answers feels instant, until the server says no and nobody planned for that.
Hammad Iqbal
Software Engineer
Optimistic updates are one of the best tricks for making an app feel fast: change the UI now, confirm with the server later. The trick has a second half that often gets skipped, which is what happens when the server rejects the change.
- Decide the failure behavior before writing the optimistic update.
- Keep the previous value so a rollback is a one-liner.
- Tell the user when something was undone, instead of silently reverting.
Snapshot before you change
Before applying the optimistic change, keep a copy of the previous state. If the request fails, restoring it is trivial. Without the snapshot you end up reconstructing the old value from guesses.
Rolling back is a UX moment
A silent revert looks like a glitch. A short message such as 'Could not save, change undone' tells the user what happened and lets them retry. The rollback is part of the feature, not an error path to hide.
Know when not to be optimistic
Payments, irreversible actions, and anything where a rejected result matters more than speed should wait for the server. Optimism fits cheap, reversible actions like toggles, reorders, and likes.
Use optimistic updates for cheap reversible actions, and always build the undo and the message together with them.
Have a project this kind of thinking applies to?
Tell me what you're building — I read every message myself.