~/papers/dynamo
paper notes · SOSP 2007
Dynamo: Amazon's Highly Available Key-value Store
Read it to understand why DynamoDB partitions behave the way they do, and why an eventually consistent read is a feature with a price tag.
- authors
- Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall, Werner Vogels
- year
- 2007
- my rating
- read
- 2025-07-22
- views
On this page
key takeaways
- 01Availability over consistency is a business decision made explicit: a shopping cart that always accepts writes beats one that is occasionally correct and down.
- 02Consistent hashing, vector clocks, sloppy quorums and hinted handoff are each simple; the paper is about how they compose.
- 03The DynamoDB you rent today is not this paper's Dynamo, but its pricing and partition behaviour still rhyme with it.
Why I read it
I was tuning DynamoDB tables for the generation-job state in Prompt-to-app BaaS: generating full-stack stores on AWS, then cutting the bill by 76% and kept hitting hot partitions. The paper explains the model the service grew out of.
Mechanism
Keys are placed on a ring via consistent hashing with virtual nodes; each key is replicated to N successors; reads and writes use tunable quorums (R + W > N for strong-ish reads); conflicting versions are kept and reconciled by the application using vector clocks.
Applied
- Partition key design became the first question in every DynamoDB schema review, not the last.
- The idea of application-level reconciliation showed up again, in a different costume, in the field-level conflict resolution of Immigration Copilot: agents that fill government forms in a real browser.
Reservations
Vector clocks and client-side reconciliation never caught on broadly; most teams want last-writer-wins and a good enough clock. The paper is honest about the cost; readers often aren't.
Related notes
Discussion (0)
name + comment · no login