Storage & File Systems
Where and How Data Physically Lives
Every system stores data somewhere, and how you store it — the storage model, the file system, the lifecycle — shapes performance, cost, durability, and scalability as much as any database choice. This topic goes beneath the database to the storage substrate: the three fundamental ways to organize data on disk (block, file, object), how file systems scale across many machines when data outgrows one, how large-scale analytical data is organized (lakes and warehouses), the crucial distinction between storage that survives and storage that doesn't (persistent vs ephemeral), and the policies that govern data's whole life (backup and retention).
What unifies these sub-topics is a set of recurring questions about the physical reality of data: Is this data structured or raw? Does it need low-latency block access or cheap web-scale storage? Does it survive when compute is replaced? How long do we keep it, and where? Getting these answers right is foundational — the wrong storage model makes a system slow or expensive, ephemeral storage misused causes silent data loss, and absent backup/retention policy causes either unrecoverable disasters or compliance violations. Storage is the ground everything else is built on.
When This Comes Up
- System design interviews: "Where do you store the uploaded images/videos?" is a near-universal question, and the right answer (object storage, not the database) signals maturity. Interviewers also probe how you'd store petabytes (distributed file systems), how you'd separate analytical from transactional data (lakes/warehouses), and how you avoid losing data on disposable infrastructure (ephemeral vs persistent).
- Real architecture: Choosing block vs file vs object storage, designing a data lake/warehouse strategy, deciding what lives on ephemeral vs persistent storage, and setting backup/retention policy are foundational infrastructure decisions that determine cost, performance, durability, and compliance.
- Production incidents: Data loss from storing must-keep data on ephemeral instances, databases crushed under BLOBs that belong in object storage, "data swamps" no one can use, and unrecoverable disasters from untested backups are all rooted in the choices here.
How the Sub-Topics Connect
The sub-topics move from the fundamental storage models (block vs file vs object) → scaling file systems across machines (distributed file systems) → organizing large analytical data (lakes and warehouses) → the survival distinction that matters on disposable infrastructure (ephemeral storage) → and the lifecycle policy that protects and expires data (backup and retention):
1. Block vs File vs Object Storage
The three fundamental storage models, differing in how data is organized and accessed. Block storage exposes raw fixed-size chunks the OS formats — fastest and lowest-latency, for databases and boot volumes. File storage offers a shared folder/file hierarchy over a network filesystem — for many machines sharing files. Object storage keeps discrete objects (blob + metadata + key) in a flat HTTP-accessed namespace — near-infinite scale, cheap, durable, for media, backups, and static assets. The modern default for application data is object storage, with the classic anti-pattern being cramming large files into a database — store the file in object storage, the metadata in the database.
2. Distributed File Systems
How you store data too big for any single machine. A DFS splits large files into chunks, distributes and replicates them across a cluster of commodity servers, and coordinates via metadata so clients see one unified filesystem. The classic architecture separates a lightweight metadata master (tracking chunk locations) from data nodes (holding the chunks), keeping the master out of the bulk-data path so it isn't a bottleneck. Replication provides durability on hardware that will fail, and data locality — moving computation to the data rather than data to compute — is the defining big-data benefit. Modern cloud data lakes increasingly use object storage in place of HDFS.
3. Data Lakes & Warehouses
Two architectures for large-scale analytical data. A data warehouse stores structured, cleaned, modeled data optimized for fast BI queries — schema-on-write. A data lake stores raw data of any type cheaply at massive scale — schema-on-read, applying structure only when read. The trade-off is rigidity-and-speed vs flexibility-and-cost, and the risk of an ungoverned lake is a "data swamp." Modern lakehouse architectures (Delta Lake, Iceberg) layer warehouse guarantees (ACID, fast SQL) onto lake-cheap object storage. Most organizations use both — a lake for cheap raw storage and ML, feeding a warehouse for governed BI — often with ELT replacing classic ETL.
4. Ephemeral Storage
The critical distinction between storage that survives and storage that doesn't. Ephemeral storage (container local disk, instance store, function memory) lasts only as long as the compute using it; persistent storage (EBS, object storage, managed databases) survives independently. This matters enormously in cloud-native systems where instances are treated as cattle, not pets — constantly killed and recreated for scaling, deploys, and healing. That disposability is what enables horizontal scaling, but it's only safe if instances hold no irreplaceable state. The test for every piece of data: if the instance vanished, could we regenerate it? — regenerable/transient data to fast ephemeral storage, irreplaceable data to durable persistent storage.
5. Backup & Retention
The policy governing data's whole lifecycle: backups are recovery copies (protecting against logical loss replication can't), and retention is how long you keep data and its backups. It balances opposing pressures — keep long enough for disaster recovery and legal compliance, but not so long that you waste storage, expand breach exposure, and violate privacy. The 3-2-1 rule (plus an immutable copy against ransomware) is the backup foundation; tiered retention with automated lifecycle tiering controls cost. The uniquely hard part is reconciling compliance (keep records for years) with privacy (delete personal data promptly) — and the non-negotiable discipline is testing restores, because an untested backup is only a hope.
Sub-Topics
| # | Sub-Topic | What You'll Learn |
|---|---|---|
| 1 | Block vs File vs Object Storage | The three storage models and when to use each |
| 2 | Distributed File Systems | Storing data too big for one machine, reliably |
| 3 | Data Lakes & Warehouses | Organizing large-scale analytical data |
| 4 | Ephemeral Storage | Persistent vs disposable storage and avoiding data loss |
| 5 | Backup & Retention | Lifecycle policy balancing recovery, cost, and compliance |