Blob / Object Storage

One-liner: Flat key→bytes store (S3-style) with HTTP access, massive durability, and cheap capacity; the default home for files, media, and backups.

Say this#

SAY THIS

Object — key + bytes + metadata; immutable (replace, don't edit).
Bucket — namespace for keys; flat, prefixes simulate folders.
Presigned URL — time-limited signed URL letting a client upload/download directly, bypassing your servers.
Multipart upload — split large objects into parts uploaded in parallel, then complete.
Storage classes / tiering — hot (Standard) → infrequent access → archive (Glacier); lifecycle rules move objects.
Eventual vs strong consistency — S3 is now strongly consistent for reads-after-write (since Dec 2020).
Durability vs availability — 11 nines durability (not losing data) vs 4 nines availability (being able to read it).
Erasure coding — data split into fragments + parity across nodes/AZs; cheaper than 3x replication.
Content-addressable — key = hash of content; free dedupe, immutable caching.
CDN origin — bucket as the origin for CloudFront/Cloudflare.
Examples — S3, GCS, Azure Blob, MinIO, Ceph RGW, Backblaze B2.

How it works#

TEXT

client --(1) POST /upload-intent--> API --(2) presigned PUT URL--> clientclient --(3) PUT bytes directly------------------------------> S3client --(4) POST /complete {key}--> API --(5) store key in DB--> Postgresviewer --GET cdn.example.com/key--> CDN --miss--> S3client --(1) POST /upload-intent--> API --(2) presigned PUT URL--> client
client --(3) PUT bytes directly------------------------------> S3
client --(4) POST /complete {key}--> API --(5) store key in DB--> Postgres
viewer --GET cdn.example.com/key--> CDN --miss--> S3

App stores only the object key/URL and metadata in the database.
Uploads go client→S3 via presigned URL (or multipart for >100 MB).
S3 event or client callback confirms; app marks record complete.
Reads served via CDN with the bucket as origin; private content via signed CDN URLs.

Why not the DB: blobs bloat the DB, slow backups/replication, and waste expensive IOPS. Why not a file system: POSIX semantics don't scale across nodes; NFS/EFS is for shared-access needs, not internet-scale serving.

Trade-offs#

Choice	Pro	Con
Object store	Cheap, durable, infinitely scalable, HTTP-native	No partial updates, higher per-request latency, no POSIX
DB blobs (bytea/BLOB)	Transactional with metadata	Bloats DB, hurts replication/backups; fine only for <~1 MB rare cases
Network file system (EFS/NFS)	POSIX, shared mounts	Cost, scaling limits, not for public serving
Presigned direct upload	Offloads bandwidth from app servers	Must validate after upload (size, type); orphan cleanup
Content-hash keys	Dedupe, cache forever	Need a mapping table for human names

Numbers#

S3: 11 nines durability, 99.99% availability design; max object 5 TB; single PUT max 5 GB; multipart parts 5 MB–5 GB, up to 10,000 parts.
S3 request rates: 3,500 PUT/s and 5,500 GET/s per prefix (scales by adding prefixes).
Presigned URL max lifetime: 7 days (SigV4).
First-byte latency from S3: order of tens of ms; CDN edge hit: single-digit ms.

Say this#

How it works#

Trade-offs#

Numbers#

In the interview#