Protocol
Make the write conditional on the version you reviewed
A careful review of yesterday's value does not authorize overwriting today's change.
When it fits
- Another person or process can edit the same record before your update reaches it.
When to avoid it
- Reading twice is not atomic protection. The check must be enforced by the receiving system, with the correct version scope.
Why it matters
Bind the update to the version that informed it. With a supported HTTP interface, an entity tag and If-Match can provide this check. If the version changed, reread and reconcile the difference instead of forcing the old update through.
Steps
- Read the value and its server-provided version together.
- Submit the change with an enforced version precondition.
- On conflict, inspect the new state and prepare a fresh, reviewed update.
An example
While you correct an address, another user changes the contact details. A version conflict prevents your stale full-record payload from silently erasing that work.
Check your result
A test that changes the record between read and write is rejected or handled as a documented conflict.
Keep this limit in mind
- Reading twice is not atomic protection. The check must be enforced by the receiving system, with the correct version scope.
Connected ideas
Useful withReverse the business effect without restoring stale history
Evidence and sources
Supports
HTTP If-Match can make a state-changing request conditional on a matching representation version and prevent lost updates.
A client-side read followed by an unconditional write is not an atomic version check.
RFC 9110: HTTP Semantics · RFC 9110, section 13.1.1