Section 1: Put Bytes, Get Bytes, Never Lose Them - Problem Understanding & Clarifications

Executive Summary: This section covers the opening minutes of a prompt that sounds like a key-value store and is really four hard problems behind one HTTP surface: eleven-nines durability on 90,000 disks that fail about five times a day, a strongly consistent ordered index over 10 trillion keys, one data path for both a 4 KB thumbnail and a 5 TB master, and fairness between tenants who share every disk. We decompose the prompt, run a clarifying exchange in which each answer kills, creates or defers work, write the assumptions down, and meet Lumen, whose 480 MB clip and 40 KB thumbnail recur in every section.

The interviewer reads the prompt and puts the marker down:

"Design a blob storage service like Amazon S3 or Azure Blob Storage. Customers create buckets and put, get, list and delete objects by key over HTTP. Objects can be anything from a 4 KB thumbnail to a 5 TB video master. The service must essentially never lose data, stay up through the loss of a data center, and serve millions of requests a second from many tenants who share the hardware."

The tempting answer: hash the key, pick three machines, write the bytes to all of them, read from any. It is the trap. That shape, hash placement with index and data on the same nodes, suits a small deployment with no ordered LIST and a single tenant, and this prompt removes all three conditions. Each clause that sounds like a feature is a constraint:

1. Durability at exabyte scale. "Never lose data" has to hold on 90,000 spinning disks, where ordinary wear kills about five a day. Repair is the steady state, not an incident.
2. A strongly consistent index over 10 trillion keys. Every request finds the object first. "List" means the index must be ordered, and ordered indexes have hot spots wherever customers write sequential keys.
3. A data path for both extremes. A 4 KB object is a latency and packing problem; a 5 TB object is a streaming, multipart and range-read problem. One API, two physics.
4. Multi-tenant fairness and blast radius. One tenant hammering a prefix at 50,000 PUTs a second, or pulling a terabit a second, must not slow everyone on the same disks and index servers.

Key Insight: The word that hides the difficulty is object. To the customer it is a file with a name. To the platform it is an index record that cannot lose a write plus bytes that cannot lose a bit, on hardware that is failing right now, and the two halves scale independently. Say that early.

Decomposing the Prompt

Map the territory first.

• What it does: create a bucket; put, get, list and delete objects by key. No update in place, no append, no rename. Saying so now saves the index design later.
• Who uses it: almost never a human. SDKs in application servers, CDNs doing origin pulls, data-lake engines scanning millions of files, backup tools writing all night.
• Why it exists: durable bytes at a price only spinning disks can reach, so every durability decision is paid for in HDD economics.
• How it's used: over HTTP, bimodally: billions of tiny objects that want latency, far fewer huge ones that hold most of the bytes and want throughput.

The decomposition lands directly on the four hard problems, and that mapping is worth drawing.

Quick check before moving on: