Two correct-looking edits can overwrite each other
Two users can open the same record, make different changes and save in sequence. Without a concurrency check, the later request may overwrite the earlier user's work using an obsolete copy. Each individual request can return success while the combined business outcome loses information.
HTTP conditional requests provide a vocabulary for making an update depend on the representation the caller reviewed. RFC 9110 describes strong validators and If-Match in relation to lost-update prevention. The server must still implement an atomic check at the persistence boundary; adding a header to the client alone does not protect the record.
Setup: define the version and conflict experience
Choose a strong representation validator or an appropriate application version token and specify which state it represents. Return it when the client reads the record. Define how the update carries that precondition and how the interface explains a conflict without discarding the user's unsaved work.
Document whether partial edits, related records or computed values share the same version boundary. A version covering only part of the displayed data may not protect the business assumption the user relied on. Keep authentication and object authorization independent: possessing a valid validator is not permission to edit.
Illustrative incident: one operator erases another's correction
An illustrative service desk lets two operators edit an asset record. The first corrects its owner; the second saves an older form containing the previous owner while updating a note. The later save silently restores the wrong owner. This is a teaching scenario, not a customer incident.
Reproduce using two browser sessions and synthetic data. Capture the read version, submitted precondition, update result and final stored state. A single-user happy-path test cannot establish that concurrent edits are safe.
Troubleshooting: inspect the comparison boundary
| Observation | Evidence | Investigation |
|---|---|---|
| Stale edit succeeds | Submitted validator and stored version | Was a precondition required and checked? |
| Concurrent edits both pass | Database update predicate | Was comparison separate from the write? |
| Every edit conflicts | Validator generation and representation rules | Is the version changing for irrelevant reasons? |
| Client retries erase work | Retry and merge behavior | Is conflict treated as an ordinary transient failure? |
Do not automatically fetch the new version token and resubmit the old form. That removes the protection by telling the server the user reviewed a state they have not actually seen.
Corrective action through atomic persistence
Make the update conditional on the expected version in the same database operation or supported transaction mechanism. If no eligible row is updated, classify the outcome accurately and avoid reporting a successful save. Follow the documented HTTP precondition semantics rather than inventing a successful response that hides a conflict.
Provide a deliberate resolution flow: reload and compare, merge non-conflicting fields where justified, or ask the user to reapply their change. Preserve the submitted edit long enough for that review. Ensure background writers and administrative scripts participate in the version policy so they do not bypass the protection.
Verification, integrity objective and SOP
Test two concurrent edits, a missing precondition, an invalid token, a deleted record and an unauthorized caller. Confirm that one stale update cannot silently overwrite a newer accepted version. Verify the user's conflict experience and accessibility as well as the database predicate.
An internal integrity SLO can measure accepted edits preserving the documented concurrency contract. Conflict frequency is a diagnostic signal, not necessarily an application outage or contractual SLA breach. The SOP should name version ownership, merge authority, audit evidence and recovery for an already overwritten record. Avoid claiming that optimistic concurrency removes every need for business-level locking.
See custom application development and database administration.
Technical reference
RFC 9110 HTTP semantics and conditional requests, reviewed 19 October 2026. Follow documentation matching the installed product version.