Overview
Dynamo is an Amazon internal, highly available key-value store for relatively small, single-key objects. The series explains how it keeps services writable during host, network, or datacenter failures by accepting temporary replica divergence, carrying causal version context, and moving semantic conflict resolution and convergence into applications and repair paths. It then connects placement, N/R/W, durability, tail latency, production measurements, and scale limits to a bounded operating envelope—not a universal replacement for relational transactions or immediate agreement.
Learning outcomes
- Dynamo keeps writes moving during partial failure by accepting temporary replica divergence and repairing it later.
- Vector clocks distinguish causally superseded versions from concurrent branches; applications decide what concurrent values mean.
- N, R, and W jointly trade write availability, replica participation, durability exposure, consistency visibility, and latency.
- Dynamo fits services that can model state as small single-key objects and own conflict, repair, and scale costs.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
Why does Dynamo remain writable when a replica is unavailable?
Dynamo writes to enough reachable replicas, using sloppy quorum and hinted handoff when a preferred host is unavailable. The write can be acknowledged under W while later handoff and repair restore intended placement; success does not mean every replica already agrees.
How does Dynamo handle conflicting versions?
Dynamo uses vector clocks to identify causal ancestry and exposes causally unrelated versions to the application for semantic reconciliation. A service may merge branches, while a session service may use timestamp-based last-write-wins.
What do Dynamo’s N, R, and W settings control?
N sets the replica count, while R and W set the minimum read and write responses required for success. Lower thresholds generally favor availability and latency; higher thresholds can reduce limited-durability windows but increase rejection and tail-latency risk.
When is Dynamo a poor fit?
Dynamo is a poor fit for multi-item transactions, immediate agreement, or applications that cannot define conflict semantics. Its reported design also assumes a trusted internal environment and a manageable scale of roughly hundreds of storage hosts.