Object Storage & Blobs (S3): Where Files Really Live
Where do the world's images, videos, and backups live? Object storage like S3 — buckets, keys, durability, object vs file vs block storage, and the golden rule: store the URL, not the blob.
🟢 Fundamentals · True fresher level → 🟠senior nuance
Where do all the world's images, videos, PDFs, and backups actually live? Not in a database, and not on one server's hard drive. They live in object storage — systems like Amazon S3 — designed to hold unlimited files cheaply and serve them to the whole planet. If a system design question involves photos, videos, or files, "store it in object storage" is almost always part of the answer. Let's understand what it is, why it's different, and when to use it.
A "blob," simply
A blob is a Binary Large OBject — any lump of file data: an image, a video, a zip, a PDF. It's opaque; the storage system doesn't care what's inside. Object storage exists to hold blobs at massive scale.
How object storage works
You put files into buckets, and each file (object) has a unique key (its name/path). To read or write, you use a simple HTTP API — PUT to upload, GET to download — often getting back a URL you can hand straight to a browser or CDN.
🟠The important mental shift: there are no real folders. It's a flat namespace — photos/2026/cat.jpg looks like a path but is just a key string. And objects are typically immutable: you don't edit an object in place, you replace it with a new version. That flatness and immutability are exactly what let it scale to trillions of objects.
Object vs file vs block storage
🟠Three storage types come up — knowing the difference is a clean senior signal:
| Type | Model | Good for |
|---|---|---|
| Object (S3) | Flat pool of objects via HTTP | Files, media, backups, static sites — huge scale |
| File (NFS) | Folders & a filesystem path | Shared drives, familiar file access |
| Block (EBS) | Raw disk volumes for a server | Databases & OS disks needing fast random writes |
Why object storage is so popular
- Effectively infinite & cheap: store petabytes without provisioning disks; you pay for what you use, and it's among the cheapest storage per GB.
- Extreme durability: providers replicate each object across many machines and data centres, quoting "eleven nines" (99.999999999%) — practically, your files don't get lost.
- Built for the web: every object has a URL, so you can serve files straight from storage, front them with a CDN, and offload all that traffic from your app servers.
What it's great for — and what it's not
🟠Use it for: user uploads (images, video), backups and archives, logs, big data lakes, and hosting a static website's assets. Don't use it for: anything needing fast, small, random writes or transactional updates — that's a database's job (on block storage). Object storage is optimised for "write once, read many," not for constant in-place edits.
The rule every senior states: store the URL, not the blob
🟠A classic design principle: don't put large files inside your database. Storing images or videos as blobs in your SQL/NoSQL DB bloats it, slows backups, and wastes expensive DB storage. Instead:
- Upload the file to object storage (S3) → get back a URL/key.
- Store just that URL in your database, next to the record.
- Serve the file from object storage (ideally via CDN), so your DB and app servers never move the heavy bytes.
A common optimisation is a pre-signed URL: your server hands the client a temporary, permissioned URL so the browser uploads/downloads directly to/from S3 — the big file never passes through your app at all. Mentioning that is a strong senior touch.
The interview-ready summary
"For files — images, video, backups — I'd use object storage like S3: each file is an object with a key in a bucket, reached over HTTP, and it's cheap, effectively infinite, and extremely durable. It's different from block storage (raw disks for databases) and file storage (folders). Crucially, I wouldn't store blobs in the database — I'd upload to S3 and store just the URL, and serve via CDN, often with pre-signed URLs so uploads go straight to S3 without touching my servers." That answer nails the concept and the design discipline interviewers look for."
What to read next
- CDN Explained — how the files in object storage reach users fast
- Design YouTube — object storage for video at massive scale
- SQL vs NoSQL — the databases that store the URL, not the blob
- ← The complete System Design guide (hub)
← Bloom filters · Resilience: retries, timeouts & circuit breakers →
