Blob Store

A blob store is a specialized storage system for unstructured data—photos, videos, audio files, documents, backups, and binary executables. Unlike databases that store structured records, blob stores handle large, opaque binary objects that can range from kilobytes to gigabytes. Every major tech company relies on blob storage: Netflix uses S3, YouTube uses Google Cloud Storage, and Facebook built Tectonic.

In system design interviews, blob storage appears in nearly every media-heavy system: video platforms, file sharing services, backup systems, and CDN backends. Understanding how blob stores achieve high durability, availability, and throughput for massive files is essential for designing scalable systems.

Why Blob Stores Matter

Traditional databases are optimized for small, structured records with complex queries. Blob stores solve a different problem entirely:

Real-world scale:

• YouTube ingests over 500 hours of video per minute
• Netflix stores petabytes of video content across multiple resolutions
• Dropbox manages billions of files for hundreds of millions of users

Core Concepts

What is a Blob?

A blob (Binary Large Object) is any unstructured data stored as a single entity. The blob store treats it as an opaque sequence of bytes—it doesn't interpret or index the content.

Common blob types:

• Media files (images, videos, audio)
• Documents (PDFs, spreadsheets)
• Backups and archives
• Log files
• Machine learning models
• Binary executables

WORM: Write Once, Read Many

Most blob stores follow the WORM pattern: blobs are written once and read many times, but rarely (or never) modified in place. Instead of updating a blob, you upload a new version.

Why WORM?

• Simplifies consistency — No need to handle concurrent writes to the same blob
• Enables aggressive caching — Immutable content can be cached indefinitely
• Supports versioning — Keep historical versions without complex merge logic
• Optimizes for append — Storage systems can use append-only structures

Storage Hierarchy

Blob stores organize data in a simple hierarchy:

Account
├── Container (bucket)
│   ├── Blob (object)
│   ├── Blob
│   └── Blob
└── Container
    ├── Blob
    └── Blob

• Account — Top-level namespace, typically per customer or application
• Container/Bucket — Logical grouping of blobs (like a folder, but flat)
• Blob/Object — The actual data, identified by a unique key within its container

Example path: myaccount/videos/user123/vacation.mp4

Storage Tiers

Cloud blob stores offer multiple storage tiers optimized for different access patterns. This is a common interview topic when discussing cost optimization.

Lifecycle policies automatically transition blobs between tiers based on age or access patterns. For example:

• Move videos not accessed for 30 days to Cool tier
• Move backups older than 90 days to Archive tier
• Delete temporary files after 7 days

High-Level Architecture

A blob store consists of several key components working together:

Components

Chunking Large Blobs

Large blobs are split into fixed-size chunks (typically 4MB to 64MB) for several reasons:

• Parallel uploads/downloads — Transfer multiple chunks simultaneously
• Distributed storage — Spread chunks across different nodes
• Efficient replication — Replicate chunks independently
• Resumable transfers — Resume from last successful chunk on failure

Original blob: 256 MB video file

After chunking (64 MB chunks):
├── Chunk 1 (64 MB) → Data Node A
├── Chunk 2 (64 MB) → Data Node B
├── Chunk 3 (64 MB) → Data Node C
└── Chunk 4 (64 MB) → Data Node A

The manager node maintains metadata mapping each blob to its chunks and their locations:

API Design

Blob store APIs are intentionally simple—the complexity is hidden in the implementation.

Core Operations

// Container operations
createContainer(containerName)
deleteContainer(containerPath)
listContainers(accountId)

// Blob operations
putBlob(containerPath, blobName, data)
getBlob(blobPath)
deleteBlob(blobPath)
listBlobs(containerPath, prefix?, marker?, maxResults?)

Upload Flow (Write Path)

1. Client initiates upload with blob name and size
2. Front-end server requests storage allocation from manager node
3. Manager node assigns unique blob ID and selects data nodes based on available space
4. Manager splits blob into chunks and assigns each to a data node
5. Front-end server streams chunks to assigned data nodes in parallel
6. Data nodes replicate chunks synchronously to replica nodes
7. Manager stores metadata (chunk-to-node mappings)
8. Client receives success with blob URL

Download Flow (Read Path)

1. Client requests blob by path
2. Front-end server asks manager node for blob metadata
3. Manager verifies access permissions
4. Manager returns chunk locations (data node IDs)
5. Client (or front-end server) fetches chunks in parallel from data nodes
6. Chunks are assembled into the complete blob

Multipart Upload

For very large files (GB+), clients use multipart upload:

1. Initiate multipart upload → receive upload ID
2. Upload parts in parallel (each part is a chunk)
3. Complete upload with list of part ETags
4. Server assembles parts into final blob

This enables:

• Resumable uploads — Resume from last successful part
• Parallel upload — Upload multiple parts simultaneously
• Progress tracking — Know exactly how much has been uploaded

Partitioning Strategy

With billions of blobs across thousands of data nodes, efficient partitioning is critical.

Partition by Full Path

Rather than partitioning by blob ID alone, partition by the full path: accountId/containerId/blobId

Why?

• Co-locates blobs from the same user/container
• Efficient listing operations (all user's blobs on same partition)
• Better cache locality

Handling Hot Partitions

Some users or containers may receive disproportionate traffic:

• Split hot partitions — Subdivide when load exceeds threshold
• Add caching — Cache frequently accessed blobs at edge
• Rate limiting — Prevent single users from overwhelming the system

Replication Strategy

Replication is essential for durability and availability. Blob stores typically use a two-level replication strategy:

Synchronous Replication (Within Cluster)

When a blob is written, it's synchronously replicated within the storage cluster before acknowledging success to the client.

• Replication factor: Typically 3 copies
• Placement: Different fault domains (racks) to survive rack failures
• Consistency: Strong within the cluster

Write acknowledged only after:
├── Primary node writes chunk
├── Replica 1 (different rack) confirms
└── Replica 2 (different rack) confirms

Asynchronous Replication (Across Regions)

After acknowledging the write, blobs are asynchronously replicated to other data centers or regions.

• Purpose: Disaster recovery, geographic availability
• Latency: Minutes to hours depending on configuration
• Trade-off: Lower latency writes, but cross-region reads may see stale data

Replica placement strategy:

1. First copy: Local data center (fast writes)
2. Second copy: Different data center, same region (survives DC failure)
3. Third copy: Different region (survives regional disaster)

Consistency Model

Blob stores typically offer strong consistency for basic operations:

How strong consistency is achieved:

• Synchronous replication within cluster
• All reads served from the same cluster until cross-region replication completes
• Metadata updates are atomic

Garbage Collection

Deleting blobs is handled asynchronously to optimize write performance:

1. Delete request → Mark blob as "DELETED" in metadata
2. Immediate response → Return success to client
3. Background GC → Garbage collector periodically:
   • Finds blobs marked deleted
   • Removes chunk data from data nodes
   • Reclaims disk space
   • Cleans up metadata

Why lazy deletion?

• Fast delete response (no waiting for chunk cleanup)
• Batch deletion is more efficient
• Allows for "soft delete" and recovery window

Delete timeline:
T=0:   User deletes blob → Marked deleted, inaccessible
T=0-1h: Soft delete window (recoverable)
T=1h+: Garbage collector removes data
T=24h: Disk space reclaimed

Streaming and Range Requests

Blob stores support efficient streaming through range requests:

GET /videos/movie.mp4
Range: bytes=1000000-1999999

This enables:

• Video seeking — Jump to any point in a video
• Resumable downloads — Continue from where you left off
• Parallel downloads — Fetch different ranges simultaneously

The blob store maps byte ranges to chunks and returns only the requested portions.

Blob Indexing

Finding specific blobs among billions requires efficient indexing:

Metadata Tags

Blobs can have key-value tags for organization and search:

{
  "blob": "vacation-video.mp4",
  "tags": {
    "user": "alice",
    "type": "video",
    "resolution": "4k",
    "uploadDate": "2024-01-15"
  }
}

Indexing Engine

A separate indexing service maintains searchable indexes:

Query: Find all videos uploaded by Alice in January 2024
WHERE user='alice' AND type='video' AND uploadDate BETWEEN '2024-01-01' AND '2024-01-31'

Deduplication

A common interview question: "How do you avoid storing duplicate files?" The answer is content-addressable storage—identifying blobs by their content hash rather than their path.

How It Works

1. Hash each chunk — Calculate SHA-256 of chunk content
2. Check existence — Look up hash in metadata store
3. Store or reference — Store new chunks, reference existing ones

User A uploads: vacation.mp4 (256 MB)
  → Chunk 1: hash=abc123 (new, stored)
  → Chunk 2: hash=def456 (new, stored)
  → Chunk 3: hash=ghi789 (new, stored)

User B uploads: same-video.mp4 (identical content)
  → Chunk 1: hash=abc123 (exists, reference only)
  → Chunk 2: hash=def456 (exists, reference only)
  → Chunk 3: hash=ghi789 (exists, reference only)

Result: Only 256 MB stored, not 512 MB

Benefits

Trade-offs

• CPU overhead — Hashing every chunk adds latency
• Metadata complexity — Must track reference counts for garbage collection
• Security consideration — Hash collisions (extremely rare with SHA-256)

Design Trade-offs

Manager Node: Single Point of Failure?

The manager node is critical—it holds all metadata. Options for high availability:

Most production systems use Paxos/Raft-based replication for the manager node.

Chunk Size Selection

Typical choice: 64 MB for video/media workloads, smaller for general-purpose storage.

Quick Reference

Blob Store vs File System vs Database

Common Blob Stores

Interview Checklist

When discussing blob storage in interviews:

• Identified need for blob store (large unstructured data)
• Mentioned chunking for large files
• Discussed replication strategy (sync within cluster, async across regions)
• Considered storage tiers for cost optimization
• Addressed consistency model
• Mentioned manager node high availability
• Considered CDN for read-heavy access patterns
• Discussed garbage collection for deletes
• Considered deduplication for backup/sync workloads

What Interviewers Look For

1. Appropriate use — Know when blob storage is the right choice vs. database storage. Don't store 100KB JSON documents in S3 or 1GB videos in PostgreSQL.

2. Understanding of internals — Explain chunking, replication, and metadata management. Show you understand how blob stores achieve their guarantees.

3. Trade-off awareness — Discuss consistency vs. availability, storage cost vs. access speed, and strong vs. eventual consistency.

4. Integration patterns — Know how blob stores fit with databases (store metadata in DB, content in blob store), CDNs (cache blobs at edge), and processing pipelines (trigger Lambda on upload).

5. Cost consciousness — Mention storage tiers, lifecycle policies, and egress costs. Cloud blob storage bills can grow quickly without proper management.