Topic S.3
Where Data Lives: Memory, Disk, Databases & Caches
In one line
Data sits in different places that trade speed for size and safety: CPU cache, RAM, SSD, databases, remote services. Knowing roughly how fast each is explains why caches exist and why every design tries to avoid slow trips.
Think of it like this
Where you keep things at home. Your desk (RAM) holds what you're using right now: tiny but instant. The cupboard (SSD/disk) holds much more but takes a moment. The storage unit across town (a remote database or another region) holds everything but needs a trip. You keep frequently used things on the desk: that's caching.
Key ideas
- 01
The LATENCY LADDER (rough orders of magnitude): reading RAM ~100 nanoseconds; reading from a fast SSD ~100 microseconds (1,000× slower); a network round-trip inside a data centre ~0.5 ms; a query to a database in the same region ~1–10 ms; a round-trip across continents ~150 ms. Phase 0's 'Numbers every engineer should know' goes deeper.
- 02
MEMORY (RAM) is fast but VOLATILE: a restart wipes it. DISK is slower but DURABLE: data survives restarts. A DATABASE is a program that stores data durably on disk and lets you query it safely by many users at once (Phase 7). A CACHE (like Redis) keeps copies of hot data in memory to avoid slow trips (Phase 10).
- 03
Two big families of databases: RELATIONAL (SQL) databases store tables with rows and relationships (PostgreSQL, MySQL) and guarantee safe multi-step changes (transactions); NoSQL databases (MongoDB, DynamoDB, Cassandra, Redis) trade some of those guarantees for flexibility or massive scale (Phase 8).
- 04
Files and blobs (images, videos, PDFs) don't belong in a database row: they go to OBJECT STORAGE (like Amazon S3), and the database stores just the link. Streams of events go to a log like Kafka (Phase 10).
Code & diagrams
Explain without notes
Why don't we keep everything in RAM if it's so much faster?
Practice
For an online photo-sharing app, decide where each piece of data lives: user profiles, photos, likes counts, the home feed for each user.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Stateful · Why state is hard
Durability, replication, CAP/PACELC, and quorums as they behave in real databases and brokers.
Stateful · PostgreSQL essentials
MVCC, VACUUM, roles, and the SQL vs NoSQL families, from the operator's side.
Stateful · Redis & caching patterns
Cache-aside with a stampede lock, TTLs, rate limiting, and sessions in Redis.
Completion checklist
I know the rough speed difference between RAM, disk, and network
I can say where profiles, files, and hot data should live