The Lost Update: Two Clients Edit the Same Resource

A lost update happens when two clients read the same resource, each changes its copy, and each writes the whole resource back: the second write replaces the first, and the first client's change disappears without any error. Nothing in a plain PUT tells the server that the second write was based on data that had already changed.

Picture two support agents with one customer's record open. Ana fixes the street address; Ben, a moment later, adds a phone number. Both press save. The customer ends up with Ben's phone number and the old, wrong address.

Why the server accepts both. Each PUT is valid on its own: a complete customer record from an authenticated agent. The server has no way to know that Ben's copy was read before Ana's save, because his request does not say which version it was based on.

The pattern is read, modify, write. Any time a client reads, changes the data locally and writes it back, another writer can come between the read and the write. It is not limited to PUT: a PATCH that sets a whole list, such as the tags on a ticket, loses a tag another client added in between.

Why nobody notices. Both agents saw "saved". The lost change surfaces later, as a parcel sent to an address someone is sure they corrected.

Two families of fix. Pessimistic locking makes the first reader hold a lock until it writes, so the second must wait; it is awkward over HTTP, where a client may never come back to release it. Optimistic concurrency lets everyone read freely and refuses a write based on an old version, which fits HTTP naturally through the ETag.

So whenever clients write back what they read, the write must say which version it was based on.