LEARN. PRACTICE. GROW.Concept and mechanism
Reading and then writing is not an atomic check. Two workers may observe the same absence and attempt to create the same item. A condition evaluated during PutItem protects that key from replacement; treat condition failure as a concurrency outcome requiring interpretation. For related changes across items, a DynamoDB transaction can provide atomicity within its supported scope. That does not include a call to an external supplier. The design must explain recovery across boundaries. Strongly consistent table reads can confirm recent state; GSIs use eventual consistency and may show the update later.
Guided application
A report can be wrong without any HTTP error. Query returns pages and applies filtering after reading items. A page without matches can still have LastEvaluatedKey. Continue with the received token and the same condition until no continuation remains; do not use Items.length as the only termination criterion. If filtering discards almost everything, review keys and access patterns because the filter does not recover consumed read capacity. Rehearsals should include empty intermediate pages, concurrent writers, and reads immediately after writes. Also check that the query retains the authorized portfolio and customer.
To create operation record op-87 once, use a conditional write on that key. If the record exists, inspect its state instead of generating another identity to bypass the condition.
Common pitfalls
Strong read treated as a lock; GSI treated as immediate confirmation; filter treated as guaranteed capacity reduction; transaction treated as protection of external systems.
Related topics: Identities and resource authorization · Secrets, keys, and useful logs
Guarantees belong to specific operations and boundaries rather than automatically covering the whole application.
Reference: DynamoDB conditional writes · DVA-C02; exam guide 2.1