Design an Object Storage Service (S3)

Data, Storage & ConsistencyHarddesign-object-storage

Design an Object Storage Service (S3)

Design durable blob storage for exabytes of immutable objects: how bytes are placed, how eleven nines of durability is achieved, and where the metadata lives.

Erasure CodingMetadata ShardingImmutable WritesStorage Tiering

Traffic & Capacity Estimates:

10 Exabytes · 500k GET/second · 11 nines durability · objects from 1 KB to 5 TB

Functional Requirements

•PUT, GET, and DELETE objects by bucket and key, with multipart upload for large files.
•Support range reads, object versioning, and presigned URLs for direct client access.
•Lifecycle rules that transition cold objects to cheaper tiers automatically.
•List objects by prefix at reasonable cost despite a flat keyspace.

Non-Functional Requirements

•99.999999999% durability across independent failure domains.
•First-byte latency under 100ms for standard-tier objects.
•Background repair must restore lost redundancy faster than independent failures accumulate.

Back-of-the-Envelope Math

Erasure coding at 10+4 costs 1.4x raw storage versus 3x for triple replication — on 10 EB, that is petabytes of hardware.
A trillion objects at 1 KB of metadata each = 1 PB of metadata, which must itself be sharded.

Key Architectural Trade-offs

Replication (fast reads and repairs, 3x cost) vs erasure coding (1.4x cost, reconstruction reads from many nodes and costs CPU).
Metadata is the real scaling problem — the data plane is nearly stateless, while the key index needs sharding, caching, and its own consistency model.
Strong read-after-write consistency for new objects is now the expectation; it constrains how aggressively the metadata layer can be cached.

Click or drag a component onto the canvas, then connect the handles to draw the data flow.

3 nodes · 2 edges

Components · 35

Client & Edge4

Compute & Gateway7

Storage & Caching11

Messaging & Streaming6

Coordination & Ops5

Intelligence2

React Flow