Two canal-lock clerks update the same Cosmos lock item a second apart. How should the application prevent the second write from silently overwriting the first?
Select an answer to reveal the explanation.
Short Explanation
Two clerks, one lock record—use the ETag like a “you’re holding version 7” ticket. On replace, If-Match makes the late write fail instead of stomping the earlier update.
Full Explanation
Cosmos DB supports optimistic concurrency with ETags. Canal-lock clerks should read the lock item, then replace it while sending the prior ETag with an If-Match (or SDK access-condition equivalent) header. If another clerk changed the item first, the stale replace fails with a precondition error instead of silently overwriting, preserving the first successful update’s intent.
Disabling all writes and requiring email to a shared inbox abandons the database concurrency model for an unscalable manual process. A timer Function that randomly deletes conflicting items overnight destroys data and does not serialize concurrent edits. Ignoring ETags and always replacing with the newest payload invites lost updates—the classic race the question asks you to prevent.
Exam caveat: clients must refresh and retry on precondition failure using the latest item; simply failing without retry UX can frustrate clerks. Upsert without ETag conditions does not provide the same protection. Session/strong consistency choices affect read freshness but are not a substitute for ETag-conditioned writes. Operational check: simulate two concurrent replaces with the same original ETag; assert only one succeeds and the loser receives a precondition failure, then retry the loser after re-read.