What a Blob Store Is

In one line: blob store appears in almost every media, analytics, or backup design. The three properties below — unstructured, flat, immutable — are what let it scale past anything a file system can do, and each one is a deliberate subtraction.

The three defining properties

Property	What it means	What it buys
Unstructured	The store does not interpret the bytes — no schema, no fields, no queries over content	Anything can be stored, and the store never has to parse, validate, or migrate it
Flat	No directories. A blob has a name inside a container, and that is the whole namespace	No tree to traverse, lock, or rebalance — lookups are a key lookup, not a path walk
Write-once, read-many	Blobs are immutable. Updates are handled by uploading a new version rather than modifying the existing object	No in-place writes means no read-modify-write, no partial-update failure modes, and safe concurrent reads

The flat namespace is the scaling trick, and folder-looking names are an illusion

A hierarchical file system stores directories as objects that must be read, locked, and updated whenever anything inside them changes. That makes a directory a contention point, and a deep tree a chain of lookups. It is why file systems struggle past a certain object count.

A blob store has none of that. photos/2024/summer/img1.jpg looks like a path but is just a key — a single string, with / carrying no special meaning to the store. There is no photos object, nothing to lock, and listing "a folder" is a prefix scan over keys rather than a directory read.

That is what allows billions of blobs in one container with no structural bottleneck, and it is why Lesson 9's listing API works on a prefix rather than a path.

Immutability is an assumption you should state, not assume silently

Note: while not all applications require WORM, we assume blobs are immutable. Updates are handled by uploading a new version rather than modifying the existing object.

And in systems like Microsoft Azure, blobs are immutable for a set interval to protect critical data.

This is a real constraint with real consequences. There is no "append 4 bytes to this video" and no partial edit — changing one byte means uploading the whole object again. If your workload does frequent small updates to large objects, a blob store is the wrong storage and you want a file system or a database.

But look at what immutability buys, because it pays for most of the rest of this chapter: safe concurrent reads with no locking, replicas that can never diverge (there is no update to arrive out of order), and caching with no invalidation problem — a blob at a given ID is the same bytes forever, so a CDN can hold it indefinitely.

The Pub-Sub chapter reached the same conclusion from a different direction: immutability turns a concurrency problem into a non-problem.

Why we need one

Blob stores are essential for data-intensive platforms like YouTube, Netflix, and Facebook. These applications generate massive volumes of unstructured data daily and require scalable, reliable, and highly available storage.

YouTube adds over a petabyte of storage daily. Each video is stored in multiple resolutions and replicated across data centers for redundancy, so the total storage footprint significantly exceeds the original upload size.

System	Blob store
Netflix	S3
YouTube	Google Cloud Storage
Facebook	Tectonic

'Significantly exceeds the original upload size' — put a multiplier on it

Ingest is the smallest of the three terms. That is why the next lesson is about cost rather than performance.

This sentence is easy to skim past, and it is the single most important capacity fact in the chapter.

A one-petabyte-per-day upload rate is not a one-petabyte-per-day storage rate. Two multipliers stack:

Multiple resolutions. One upload becomes 240p, 360p, 480p, 720p, 1080p, 4K — call it 2–3x the original in total, since lower resolutions are much smaller but there are several.
Replication across data centers. Lesson 10 keeps a local copy, a second in another data center in the region, and a third in another region — 3x on top of that.

So a petabyte uploaded plausibly becomes 6–10 petabytes stored, every day. That is the number that makes cost the dominant design concern, and it is exactly why the next lesson is about access tiers rather than about performance.

In an interview, saying "uploads times transcoding fan-out times replication factor" shows you understand that raw ingest is the smallest of the three terms.

Use cases

Blob storage supports applications requiring efficient storage and delivery of unstructured data:

Serving images and documents directly to browsers.
Distributed file storage for multiple users.
Streaming video and audio content.
Backups, disaster recovery, and archiving.
Data lakes for on-premises or cloud-based analysis.

These five have very different access patterns — which is why tiering exists

Read them again with frequency in mind. Serving images to browsers is constant, latency-sensitive access. Archiving is write once, read approximately never — and when you do read it, waiting hours is acceptable. Data lakes are large sequential scans, occasionally.

One storage system serving all of these at one price and one performance profile would be wrong for most of them: you would either overpay enormously for archives or make the browser path too slow.

That is precisely the problem access tiers solve, and it is why the next lesson matters commercially rather than just technically.

Key takeaway

A blob store holds unstructured data in a flat namespace under a write-once, read-many assumption. The flat namespace removes the directory bottleneck that limits file systems; immutability removes locking, replica divergence, and cache invalidation. And upload volume is the smallest term in the storage bill — transcoding fan-out and replication multiply it several times over.

Interview signal by level

Level	What a strong answer sounds like
L4	"It stores files like images and videos — something like S3."
L5	Names the properties: "unstructured data in a flat namespace, write-once-read-many — updates create a new version rather than modifying in place."
Staff+	Explains what each property buys: "the flat namespace means folder-looking names are just keys, so there's no directory object to lock and listing is a prefix scan — that's what lets one container hold billions of blobs. And immutability is what makes replicas unable to diverge and CDN caching invalidation-free. On capacity, uploads are the smallest term: multiply by transcoding fan-out and replication factor, so a petabyte ingested is more like six to ten stored."

Next: how the cost of all that storage gets managed.