Skip to content
Preptima
mediumConceptDesignScenarioMidSeniorStaff

Two clients open the same record, both edit it, and the second save silently overwrites the first. How would you use ETags to turn that lost update into something the client can see and handle?

Return a strong ETag on GET, require If-Match on writes, and reject a stale token with 412 Precondition Failed so a lost update becomes a visible error rather than silent data loss. What makes it correct is that the comparison and the write must be one atomic operation - an UPDATE guarded by the version in its WHERE clause - because a SELECT then UPDATE reintroduces the race.

4 min readUpdated 2026-08-16Target archetype: Big Tech, Enterprise Captive, Product Startup

Answer

Short answer

Give every representation a version token in an ETag header on GET, and require the client to echo it in If-Match on PUT, PATCH or DELETE. The server compares the token against the current state and rejects a stale one with 412 Precondition Failed. The lost update becomes an error the client can react to instead of data quietly disappearing.

Was this answer helpful?

Likely follow-ups

  • A client omits If-Match entirely. What should the server do, and what does that choice cost you?
  • Your ETag is a hash of the JSON response and a proxy re-serialises it. What breaks?
  • How would this differ for PATCH compared with PUT? What about DELETE?
  • When would you put a version field in the request body instead of using a header?
  • The client gets a 412. Design the user experience from there.

Related questions

Masterclass guide

Further reading

Related Topics