Consistency and partitioning · Chapter 1 of 1
How databases trade consistency for speed
Distributed systems must choose between immediate data consistency and low read latency, forcing application design to handle stale reads.
FoundationsBuilds the idea from nothing. No prior AWS assumed.
The speed of light limits consistency
Why cannot every database read immediately return the latest write?
Both nodes in the distributed database cluster initially store the same synchronized data value of one hundred dollars.
- 01
Physical distance creates delay
To prevent data loss from physical accidents, AWS replicates your data across multiple servers and Availability Zones. Because network packets cannot travel faster than the speed of light, transmitting data across these physical distances requires a measurable duration. This physical constraint forces a trade-off between write speed and read correctness.
- 02
The choice at the write boundary
A database can wait for every replica to confirm a write before telling the application it succeeded. This guarantees consistency but makes writes slow. Alternatively, the database can confirm the write immediately and copy the data to replicas in the background, which speeds up writes but allows stale reads.
- 03
Stale reads are the price of speed
When replication occurs in the background, a client reading from a secondary replica might retrieve old data. This behaviour is eventually consistent. The system will become consistent when replication completes, but applications must tolerate the temporary discrepancy.
Check yourself
What is the primary physical constraint that prevents databases from having both zero write latency and immediate global consistency?
Under the hoodThe same thing from underneath: limits, failure modes, numbers.
How AWS implements replication
How do S3, DynamoDB, and RDS replicate data across their nodes?
Both nodes in the distributed database cluster initially store the same synchronized data value of one hundred dollars.
- 01
DynamoDB uses a three-node quorum
DynamoDB stores three copies of your data across different Availability Zones. When a write occurs, the leader node sends the data to two peer nodes. The write succeeds as soon as two of the three nodes acknowledge it, meaning one replica might be temporarily stale.
- 02
Read paths determine consistency
An eventually consistent read in DynamoDB queries a random replica node, which might return stale data. A strongly consistent read queries two nodes to compare their version numbers, ensuring the latest write is returned. This coordination doubles the read capacity units consumed by the query.
- 03
Amazon RDS replication is asynchronous
Amazon RDS read replicas use native database replication engines. The primary database writes changes to its transaction log and returns success to the client immediately. The replica reads this log and updates its own storage in the background, causing replication lag.
- 04
S3 achieved strong consistency
Amazon S3 provides strong read-after-write consistency for PUT and DELETE operations on all objects. Previously, S3 used eventual consistency, which meant listing bucket contents immediately after an upload could omit the new object or return outdated metadata.
The numbers
- DynamoDB write quorum
- 2 out of 3 nodesAcknowledging writes at a majority of nodes protects data against a single Availability Zone outage.
- DynamoDB strong read cost
- 2x read capacity unitsStrong reads query two nodes instead of one to resolve version differences.
- Typical RDS replication lag
- Less than 1 secondHeavy write workloads or network congestion can increase this delay to minutes.
- S3 read-after-write consistency
- Strongly consistentApplies to creation, updates, and deletions of objects in all buckets.
Check yourself
Why does a strongly consistent read in DynamoDB consume twice the read capacity units of an eventually consistent read?
In practiceThe judgement call you actually have to make.
Designing for stale data
When is eventual consistency acceptable in an application?
- 01
Eventual consistency is the sensible default
Most application interfaces tolerate minor delays. A social media count, a user profile photo update, or a search index result does not fail if a change takes 500 milliseconds to appear. Eventual consistency reduces costs and increases read throughput.
- 02
Strong consistency is for financial correctness
When updating bank balances, reserving stock items, or managing seat bookings, eventual consistency allows double-spending and overbooking. These workflows must use strongly consistent reads or conditional writes to prevent business logic errors.
- 03
Do not read your own writes from replicas
A common error is routing a user to a read replica immediately after they perform a write. The user edits their bio, the page reloads from a stale replica, and the old bio appears, leading the user to submit the form again. Keep write sessions on the primary node.
Check yourself
Which application scenario requires strongly consistent reads?
Official references & further reading
These lessons simplify selected behaviors for learning. Verify current service limits, Region support and production requirements with the official references. Experiments describe their own assumptions.
Report an error or suggest a clearer explanation →