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. Clients read an item, then replace with If-Match (or SDK access-condition equivalents) so a concurrent change yields a precondition failure instead of a silent overwrite. Ignoring ETags invites lost updates; deleting items or abandoning writes is not the concurrency pattern.