The encyclopedia · Engineering & Operations · Technical decision · 2007
Amazon's Dynamo kept the cart always writable and tuned consistency last.
Amazon built Dynamo so a cart is never unavailable, using eventual consistency, versioning and a sloppy quorum instead of a strong one.
Amazon
the move
During peak Amazon traffic, tens of millions of customers use tens of thousands of servers, and the shopping cart has to accept anything they add. A database that refuses writes while it repairs a node would lose sales, so the requirement is availability, not strict consistency.
Dynamo stores data as key-value blobs, partitions and replicates them with consistent hashing, and versions every write so concurrent edits can be reconciled later with vector clocks. Reads and writes only need a quorum, and a 'sloppy' quorum lets a write land on a temporary node while the true owner is unavailable, then get copied back on recovery.
The result is a system that keeps accepting writes, returns a coherent value once the versions are reconciled, and reserves strict consistency for the small set of services that truly need it.
why it works
- Always-writable means a busy sale never turns into a lost order
- Versioning lets a conflict be resolved later rather than block the write
- Consistent hashing spreads load without a central index to move around
- A sloppy quorum keeps the write alive while a node is down
what transfers
Choose the guarantee that fits the job: if the product is 'the thing you put in the cart must not vanish', tune for availability first and make consistency a repair step, not a precondition.
what came after
Dynamo's design paper (SOSP 2007) became the reference for highly available, eventually-consistent stores, strongly influencing systems such as Cassandra, Riak and Voldemort, and the idea of trading consistency for availability spread across web-scale infrastructure.
references
spotted an error? The archive wants to know.