Object and blob storage

Immutable files by name, replicated and cheap.

System design conceptStorage and data1 Nov 2026

01The intuition

The problem it solves

A photo studio stores negatives in numbered envelopes in a warehouse. The envelope never changes once filed; you either fetch the whole thing or you do not. Nobody edits a negative in place, nobody searches inside one, and the warehouse's whole job is to never lose an envelope and to hand it over quickly when asked by number.

Files on the internet, photos, videos, backups, build artifacts, are the same. They are large, written once, read many times, and only ever fetched whole or in large pieces. A database is built for small records that change; putting a 4 GB video in it is like filing a negative in a ledger. Object storage (blob storage) is the warehouse: billions of immutable objects, each under a name, with durability as the first promise and cost per byte as the second.

Build it one piece at a time

Step 1: the interface. Three operations: PUT bucket/key bytes, GET bucket/key, DELETE bucket/key, plus listing keys by prefix. No update in place: a changed file is a new PUT, which usually gets a new key or a new version. Flat namespace; "folders" are just key prefixes like photos/2026/.

Step 2: separate the index from the bytes. A metadata service maps each key to where its bytes are (which storage nodes, which offsets) and holds size, checksum and owner. The data nodes hold bytes and nothing else. A GET is a metadata lookup and then a direct read from a data node (metadata versus content).

After step	PUT "photos/a.jpg"	GET "photos/a.jpg"
2	bytes to one data node, index row written	index lookup, read from that node
3	bytes to three data nodes in three racks, then the index row	read from any of the three
4	large file cut into 64 MB parts, each placed independently	parts fetched in parallel and streamed

Step 3: replicate before acknowledging. The bytes go to three data nodes in different racks (or zones), and only after all three confirm is the index updated and the client told "stored". The checksum is stored with each copy so a silently corrupted disk is detected on read and repaired from another copy.

Step 4: handle big objects. Objects above a threshold are uploaded as parts; each part is placed on its own nodes and the index records the part list. Uploads resume at the part that failed, and reads stream parts in parallel.

Step 5: cut the cost. Three full copies cost 3× the bytes. Erasure coding stores the same durability in about 1.5×. Objects not read for 30 days move to colder, cheaper disks; objects never read move to tape-like tiers with minutes of retrieval time. Lifecycle rules do this automatically by age and access.

Why it works, with the numbers

Immutability is the trick. Because an object never changes after it is written, every copy of it is correct forever, which makes replication, caching and erasure coding simple: there is no "which copy is newest" question. Durability comes from independent copies and background scrubbing:

with 3 copies in 3 zones, a 1-in-50 yearly disk failure rate and repair within a day, P(lose an object per year) ≈ 3 × (1⁄50 × 1⁄365)² ≈ 10⁻⁸, and erasure coding does better still

Cost scales with bytes, not with objects, so the index must stay small (a few hundred bytes per object) and the bytes must go on the cheapest medium their access pattern allows. The guarantees are that a confirmed PUT is never lost and that a GET returns exactly the bytes that were put. The failure modes are listing a prefix with a billion keys (paginate), a key that is hot (an object everyone downloads at once belongs behind a CDN), and an application that treats objects as mutable and reads a half-written one (there is no half-written object; the key appears only when the PUT completes).

The trade-off you must say out loud

You give up in-place updates, transactions and queries over content; you get durability and cost per byte that no database approaches. Say which bytes go here and which facts stay in a database, and say the write order (object first, then the record that points to it). The next question is usually "how do you serve a million downloads of one object?", and the answer is edge caching, not more replicas.

Where it shows up in the 100 Google problems

Design a blob / object storage service: the question is this article taken all the way down to disks and erasure coding.
Design Google Drive: file chunks are objects; the folder tree is metadata elsewhere.
Design Google Photos: originals and generated thumbnails are objects at different tiers.
Design an image and GIF hosting service: every upload is an immutable object served through a CDN.
Design a distributed file system (GFS): the older cousin: chunks on chunkservers, a master holding the index.