Design S3-Like Object Storage
From one server writing files on disk to an exabyte store that survives an entire data-centre dying — the metadata/data split, erasure coding, placement across failure domains, and repair as the real durability lever.
System design · Systems. The source ↗
A free, interactive, animated visual explainer of Design S3-Like Object Storage — built to be understood, not skimmed.
Questions
- How does object storage achieve eleven nines of durability?
- Not with a single trick but with a chain: an object is chunked and erasure-coded into k data + m parity shards, the shards are placed across independent failure domains (racks, then Availability Zones), and a background repair process rebuilds any lost shard fast — before enough others fail to cross the threshold. Amazon S3 is "designed to provide 99.999999999% durability" by combining these across a minimum of three Availability Zones.
- Why not just keep three copies of every object (3x replication)?
- At exabyte scale the cost is prohibitive. Three full copies is 200% storage overhead; erasure coding like Reed-Solomon RS(6,3) gives comparable fault tolerance at no more than 50% overhead — HDFS notes a 6-block file costs 18 blocks replicated but only 9 blocks erasure-coded. Replication is still used for tiny objects, where per-shard overhead and extra read I/O make coding a net loss.
- What is the metadata/data split in object storage?
- Two planes that scale differently. The data plane holds the object bytes (huge, sequential, erasure-coded). The metadata plane is the index that maps bucket+key+version to the shard locations — small per object but the hot path for every request and the true durability bottleneck: if the metadata is lost the healthy bytes become unfindable, so the metadata itself must be replicated and strongly consistent.
- How does erasure coding survive losing a whole data centre?
- By placement. With RS(6,3) an object becomes 9 shards; spread three-per-Availability-Zone across three AZs, losing an entire AZ removes exactly 3 shards, leaving 6 — precisely the k needed to reconstruct the object. Any k of the n shards rebuilds the original, so the AZ loss is a rebuild, not a data-loss event. S3 is "designed to sustain data in the event of the loss of an entire Amazon S3 Availability Zone."
- Why is repair speed the real lever for durability, not the number of copies?
- You only lose data if more than m shards fail inside the repair window — the time to rebuild the first failure. Backblaze models this directly: with a ~0.41% effective annual drive-failure rate and a 6.5-day average rebuild, four drives must fail before the first is rebuilt to lose a file, which works out to eleven nines. Halve the repair window and durability climbs by orders of magnitude with no extra storage.