Comparison
Optimistic lockingvsOptimistic UI
Optimistic locking
you read the row with its version, write it back only if the version has not changed, and retry the whole thing if it has.
Detecting conflicts at write time by checking that the record has not changed since you read it, usually via a version or timestamp column. There is no lock held, so readers never block and there is no deadlock risk. It works well when conflicts are rare, and degrades badly on hot rows where retries pile up.
Full entry →Optimistic UI
the item appeared in the list the instant you clicked, before the server had confirmed anything.
Applying the expected result of a mutation locally and reconciling when the response arrives. It removes the network from the perceived interaction, which for a like button or a checkbox is the whole experience. It requires you to write the rollback path too, and to decide what to show when the rollback happens — a state most implementations forget until someone loses work on a flaky connection.
Full entry →