In DynamoDB, what is the difference between an eventually consistent read and a strongly consistent read, and how does that choice change the read capacity a request consumes?

## Why there is a choice at all DynamoDB replicates every item synchronously across multiple facilities in a Region before acknowledging a write. A write is durable once a quorum of replicas has it, but the remaining replicas converge a moment later — normally within milliseconds. That short window is the whole reason DynamoDB exposes two read modes: a read that can be answered by *any* replica is cheaper and more available, and a read that must see the newest data has to be routed more carefully. ## The two modes **Eventually consistent read** is the default for every read API. The request may be served by a replica that has not yet applied the most recent write, so a read immediately following a successful `PutItem` can return the previous value — or, on a brand-new item, no item at all. In practice the staleness window is very small, which is exactly what makes it dangerous: it will not show up in a hand test and will show up under load in production. **Strongly consistent read** is requested per call by setting `ConsistentRead` to true. DynamoDB then guarantees the response reflects all writes that received a successful response before the read began. You pay for that in three currencies: capacity (double), latency (slightly higher), and availability (a strongly consistent read can fail if the relevant replica is unreachable, where an eventual read would have succeeded from another copy). ```bash aws dynamodb get-item \ --table-name Orders \ --key '{"orderId":{"S":"A-1001"}}' \ --consistent-read \ --return-consumed-capacity TOTAL ``` `--return-consumed-capacity TOTAL` is the honest way to learn the cost of a call: the response carries the units actually consumed rather than your estimate of them. ## The capacity arithmetic One **read capacity unit** (RCU) provides, per second: - one **strongly consistent** read of an item up to 4 KB, - two **eventually consistent** reads of an item up to 4 KB, - one half of a **transactional** read of an item up to 4 KB — that is, a transactional read costs 2 RCU. Item size is rounded up to the next 4 KB boundary, so a 5 KB item costs two units strongly consistent and one unit eventually consistent. Writes have their own scale — a write capacity unit covers an item up to 1 KB, a transactional write costs 2 WCU — and there is no consistency choice on writes at all, which is a common point of confusion: *consistency is a read-side option*. The same arithmetic applies in on-demand mode, where the units are called read request units and write request units and are billed per request rather than reserved per second. For a `Query` or `Scan`, capacity is charged on the total size of the items **read**, not the items returned after a filter expression. A filtered scan that examines a megabyte and returns one item still bills for the megabyte — the single most common surprise on a DynamoDB bill. ## Where strong consistency is not available A global secondary index is maintained asynchronously from the base table, so reads from a GSI are **always** eventually consistent; `ConsistentRead=true` on a GSI query is rejected. If a read path genuinely needs read-after-write, it has to go to the base table. ## Choosing in practice Default to eventual reads. They halve the capacity bill, cut a little latency, and survive a replica hiccup. Reach for strong consistency on the narrow set of paths where a client will read back something it just wrote and a stale answer would be a visible bug — a checkout flow that immediately re-renders the order it just created, an idempotency check, a workflow step that gates on a status field another step just set. The better fix for many read-after-write cases is not to read at all: `PutItem` and `UpdateItem` accept `ReturnValues`, so an update can hand back the new item without a second round trip and without paying for a strongly consistent read. ```bash aws dynamodb update-item \ --table-name Orders \ --key '{"orderId":{"S":"A-1001"}}' \ --update-expression "SET orderStatus = :s" \ --expression-attribute-values '{":s":{"S":"SHIPPED"}}' \ --return-values ALL_NEW ``` ## Saying it well A crisp answer names the default (eventual), the flag (`ConsistentRead`), the exact 2:1 capacity ratio, and one concrete situation where you would pay for strong consistency. Adding that GSIs cannot serve strongly consistent reads, and that a transactional read costs double again, marks you as someone who has actually sized a table rather than read a summary of one.