What is the difference between eventually consistent and strongly consistent reads in DynamoDB?
Compare DynamoDB eventually consistent and strongly consistent reads: freshness, RCU cost, latency, GSI limits, and how to choose per request.
Expected Interview Answer
An eventually consistent read may return slightly stale data because it can be served from any replica that might not yet have the latest write, while a strongly consistent read always returns the most up-to-date data reflecting all successful prior writes.
DynamoDB replicates every write across multiple storage nodes in different Availability Zones. By default reads are eventually consistent, meaning they can hit a replica that hasn't yet received the newest write, so the result may be a fraction of a second behind. A strongly consistent read routes to the leader replica to guarantee the latest value, but it costs twice as much (one full RCU vs half), has slightly higher latency, isn't available on global secondary indexes, and can fail if the leader replica is unreachable.
- Eventually consistent reads cost half the RCUs and offer higher throughput
- Eventually consistent reads have lower latency and better availability
- Strongly consistent reads guarantee you never read stale data
- Choice can be made per-request via ConsistentRead
- Lets you trade cost and speed against freshness where each read allows
AI Mentor Explanation
A strongly consistent read is like asking the on-field umpire for the exact current score — always right, but it takes a moment and costs more attention. An eventually consistent read is glancing at a boundary-side scoreboard that updates a beat later: usually correct, occasionally a ball behind, but instant and effortless to check.
Step-by-Step Explanation
Step 1
Understand the default
DynamoDB reads are eventually consistent unless you explicitly request strong consistency.
Step 2
Request strong consistency when needed
Set ConsistentRead: true on GetItem, Query, or Scan to always read the latest committed data.
Step 3
Weigh the cost
A strongly consistent read costs one full RCU vs half for eventually consistent, doubling throughput cost.
Step 4
Know the limitations
Strong consistency isn't available on global secondary indexes and may fail if the leader replica is unavailable.
Step 5
Decide per read
Use strong reads where staleness is unacceptable (e.g., read-after-write) and eventual reads for cheap, high-volume queries.
What Interviewer Expects
- Clear definition of both consistency models
- Knowing eventual is the default and can be stale for a short window
- Understanding strong reads cost 2x (one full RCU) and add latency
- Awareness that GSIs only support eventual consistency
- Ability to choose per-request via ConsistentRead
Common Mistakes
- Thinking eventual consistency means data is permanently wrong rather than briefly stale
- Assuming strongly consistent reads are available on global secondary indexes
- Forgetting strong reads cost twice the RCUs of eventual reads
- Believing all reads are strongly consistent by default
- Ignoring that strong reads can fail if the leader replica is down
Best Answer (HR Friendly)
“A strongly consistent read always gives you the very latest data, while an eventually consistent read is faster and cheaper but might occasionally be a split second out of date. You pick the strong one when accuracy matters most and the eventual one when speed and cost matter more.”
Code Example
import { DynamoDBClient } from '@aws-sdk/client-dynamodb'
import { DynamoDBDocumentClient, GetCommand } from '@aws-sdk/lib-dynamodb'
const doc = DynamoDBDocumentClient.from(new DynamoDBClient({ region: 'us-east-1' }))
// Default: eventually consistent (cheaper, may be slightly stale)
const eventual = await doc.send(new GetCommand({
TableName: 'Accounts',
Key: { accountId: 'A-1001' },
}))
// Strongly consistent: always the latest data, costs 2x RCUs
const strong = await doc.send(new GetCommand({
TableName: 'Accounts',
Key: { accountId: 'A-1001' },
ConsistentRead: true,
}))
console.log(eventual.Item, strong.Item)Follow-up Questions
- Why can't global secondary indexes serve strongly consistent reads?
- How does DynamoDB replicate writes across Availability Zones?
- What is read-after-write consistency and when do you need it?
- How does consistency choice affect capacity unit consumption?
- How do DynamoDB transactions relate to read consistency?
MCQ Practice
1. What is the default read consistency in DynamoDB?
DynamoDB reads are eventually consistent by default; you opt into strong consistency with ConsistentRead: true.
2. Compared to an eventually consistent read, a strongly consistent read costs:
A strongly consistent read consumes one full RCU versus half an RCU for an eventually consistent read — double the cost.
3. Which structure does NOT support strongly consistent reads?
Global secondary indexes only support eventually consistent reads; base tables and LSIs support strong reads.
Flash Cards
What is an eventually consistent read? — A read that may return slightly stale data from any replica; it's the default, costs half an RCU, and is faster.
What is a strongly consistent read? — A read routed to the leader replica that always returns the latest committed data; costs a full RCU with higher latency.
Do GSIs support strong reads? — No — global secondary indexes only support eventually consistent reads.
How do you request a strong read? — Set ConsistentRead: true on GetItem, Query, or Scan.