How Does DynamoDB Handle Consistency in Read Operations?
Amazon DynamoDB offers two read consistency models for query and get item operations: eventual consistency and strongly consistent reads. By default, DynamoDB uses eventually consistent reads, which optimize for throughput and lower latency by returning data that may not immediately reflect the results of a recent write operation across all storage locations. Conversely, strongly consistent reads guarantee that the returned data reflects all successful writes prior to the read, though this choice comes at the cost of higher latency and double the read capacity unit consumption.
Eventual Consistency in DynamoDB
When data is written to a DynamoDB table, it is automatically replicated across multiple Availability Zones within an AWS Region to ensure high availability and durability. In an eventually consistent read, DynamoDB routes the read request to one of the storage nodes hosting a replica of the data.
Because replication across nodes takes a fraction of a second, an eventually consistent read might briefly return stale data if executed immediately after a write. However, eventual consistency provides key operational advantages:
- Lower Latency: Responding from a single replica yields faster response times.
- Higher Throughput: Eventual consistency uses half the Read Capacity Units (RCUs) compared to strong consistency (one RCU handles up to 8 KB per second for eventual consistency).
- Maximum Availability: Read operations succeed even if one replica is temporarily unreachable or catching up.
Strongly Consistent Reads
When an application requires guaranteed data accuracy—such as
financial transactions, inventory checks, or access control validation—a
strongly consistent read can be explicitly requested by setting the
ConsistentRead parameter to true.
When a strongly consistent read request is received, DynamoDB queries the leader node or polls a quorum of storage nodes to ensure the returned item includes all successful write operations that received an acknowledgment prior to the read.
- Guaranteed Freshness: Returns the most up-to-date state of the item.
- Higher Cost: Consumes double the throughput (one RCU handles up to 4 KB per second for strong consistency).
- Potential Latency: Waiting for quorum or leader state verification slightly increases response latency.
Key Differences and Comparison
Choosing between consistency models depends on performance requirements, cost sensitivity, and business logic needs.
| Feature | Eventual Consistency (Default) | Strong Consistency |
|---|---|---|
| Data Freshness | May reflect slight replication lag | Always reflects all prior successful writes |
| Read Capacity Units | 1 RCU per 8 KB | 1 RCU per 4 KB |
| Latency | Lowest possible latency | Slightly higher latency |
| Availability | Highest availability across replicas | Dependent on leader node/quorum availability |
| Global Tables Support | Fully supported across all regions | Supported within local region only |
Secondary Indexes Considerations
The consistency model behavior also varies depending on the type of index used:
- Local Secondary Indexes (LSIs): Support both eventually consistent and strongly consistent reads, as LSIs share the same partition key space and storage nodes as the main table.
- Global Secondary Indexes (GSIs): Only support eventually consistent reads. Data from the base table is asynchronously copied to the GSI, so queries against a GSI cannot guarantee immediate strong consistency.