LEARN. PRACTICE. GROW.Round the correct operation
For GetItem, a strong read of an item up to 4 KiB consumes one read unit; an eventual read consumes half. A 6 KiB item occupies two blocks, giving two strong units or one eventual unit. For BatchGetItem, round each item separately: 1 KiB and 5 KiB items require three strong units. Do not transfer this rule uncritically to Query, which aggregates sizes before rounding. Identify operation, size, and consistency before calculating; request rate alone is insufficient.
Separate consumption, response, and price
A ProjectionExpression returning 100 bytes from a 9 KiB item does not reduce GetItem consumption to 100 bytes: the strong read still uses three units. For nontransactional UpdateItem, use the larger before-or-after size and round to 1 KiB blocks; 2.2 to 2.6 KiB requires three write units, excluding indexes in this example. These calculations teach consumption. Monetary estimates still require capacity mode, region, indexes, and other services used.
Choose consistency on the access path
Tables and local secondary indexes support strong reads; global secondary indexes do not. Requesting ConsistentRead on a GSI does not turn it into a strong-read target. If confirmation requires immediate freshness, reconsider table access or an appropriate LSI instead of adding an invalid option. These exercises use one Region. Do not generalize that all global tables always use eventual consistency: distinct consistency modes and requirements exist. In the design, write the requirement beside each access rather than only in the database title.
Make the condition part of the update
Two workers can read balance 100, both decide to reserve 80, and only then write. A strong read does not block the other worker’s change between these operations. In the single-item exercise, UpdateItem with balance>=80 checks and updates atomically; the first reservation leaves 20 and the second condition fails. Handle that result in the application. This does not automatically coordinate an external payment call. Stable identity, destination idempotency, and reconciliation remain relevant when effects cross systems.
Do not use cleanup as authorization
DynamoDB TTL deletes items asynchronously. If a token expires at 12:00, its presence at 12:01 does not make it valid. The application should enforce expiration during authorization while TTL handles cleanup. Similarly, DAX does not remove consistency choices: strong reads pass through to DynamoDB and are neither served from nor stored in the DAX cache. A caching solution must match read semantics rather than merely a desire to reduce latency.
Distribute keys and prepare operations
A partition key equal to today for every write can concentrate traffic even when total capacity looks sufficient. Start with access patterns and key distribution. Sharding can spread load but also changes queries, aggregation, and maintenance; it is not a free choice. For 120 GetItem requests per second over 6 KiB, half strong and half eventual, consumption is 60×2+60×1=180 read units per second. That total still does not establish suitable distribution, burst tolerance, or acceptable latency.
Two workers try to reserve 80 from balance 100; one successful conditional update leaves 20 and prevents the second reservation.
Common pitfalls
Using a GSI for strong reads, TTL for immediate revocation, or read-then-write as an atomic operation.
Related topics: Idempotency · Data modeling
Consistency, atomicity, capacity, and validity are different requirements requiring explicit decisions.
Reference: DynamoDB read and write operations · SAA-C03