Two clerks may update the same case-notes item concurrently. How should the app prevent silent overwrites in DynamoDB?
Select an answer to reveal the explanation.
Short Explanation
Don’t let the second clerk’s save stomp the first. Stamp a version (or condition) and refuse the write when the item changed underneath—classic optimistic locking.
Full Explanation
Concurrent clerk updates to the same case-notes item need optimistic concurrency control in DynamoDB. Use conditional expressions—commonly comparing a version (or updatedAt) attribute so UpdateItem or PutItem succeeds only when the expected version still matches—to prevent silent last-writer-wins overwrites. The second clerk then refreshes, reconciles, and retries with a clear conflict path instead of erasing a colleague’s notes.
Always using Scan then PutItem with no conditions is both racy and unnecessarily expensive for a known item key. Disabling IAM so either clerk can overwrite without checks removes authorization controls and still allows silent overwrites. Storing notes only in Amazon SNS messages abandons a durable shared item and provides no concurrency control for case-notes state.
Exam caveat: conditional check failures return an error the application must handle—surface a conflict to the clerk rather than blindly retrying with a stale payload that will fail again or, worse, bump a version incorrectly. Operational check: simulate two writers holding the same version, confirm only one UpdateItem succeeds, and verify the loser receives ConditionalCheckFailedException (or equivalent) and must re-read before saving successfully.