Two application processes read the same DynamoDB item at nearly the same time, each intending to update a different attribute, and the team wants to guarantee that neither process silently overwrites a change made by the other between the read and the write. Which mechanism should the application implement?
- Enable DynamoDB Streams so each process can see the other's writes after the fact
- Use a global secondary index so each process writes to a different index
- Increase the table's provisioned write capacity so both writes always succeed
- Include a ConditionExpression that checks a version attribute matches the value read, so a concurrent write causes the losing process's request to fail with a conditional check failure
Why D? And why not the others?
Correct answer: D. Include a ConditionExpression that checks a version attribute matches the value read, so a concurrent write causes the losing process's request to fail with a conditional check failure
Optimistic locking in DynamoDB works by storing a version number on each item and having every update include a ConditionExpression that the current version still equals the value the process originally read; if another process updated the item in between, the version will have changed and DynamoDB rejects the second write with a conditional check failure instead of silently applying it, letting the application detect the conflict and retry with fresh data. The option describing DynamoDB Streams is wrong because Streams only reports changes after they have already been committed; it cannot prevent a write from happening and does not stop a silent overwrite. The option describing a global secondary index is wrong because writing to different indexes does not change the fact that both processes are updating the same base-table item, and indexes are a query mechanism, not a concurrency-control mechanism. The option describing increased write capacity is wrong because provisioned throughput only affects whether requests get throttled for capacity reasons; it does nothing to detect or prevent one process's write from overwriting another's uncommitted assumptions about the item's prior state.
Source: AWS DynamoDB documentation: optimistic locking with a version number