Choosing Where Data Lives

9.Choosing Where Data Lives

M

In this chapter

We'll close the Act by turning the course's own opening incident into four real, diagnosed problems, build a real five-question framework for choosing where any data should live, and preview exactly what Acts 2 through 7 each go deep on.

8–10 min

The Problem in Real Life

Mike looks back at the diagnostic screen from the very start of this Act — the same four red lines, still sitting there, still unresolved. But he's reading it differently now.

"Cart, lost on refresh — that's volatile storage that never became persistent," he says, working through it himself. "Images not loading, old prices — that's something about caching, or where the images actually live. Page load slow — that's a real latency cost, somewhere in the chain."

M

I actually know where to look now. I didn't, this morning.

Mike

One Vague Incident vs. Four Real, Diagnosable Problems

One incident, four real, separate diagnoses

The lost cart, slow page, missing images, and stale prices each point at a specific, nameable storage concept — not one vague problem.

A real five-question framework

Durability, latency, capacity, access pattern, and shape — the same real questions every later Act in this course adds depth to.

Choosing Where Data Lives

Mike just did, out loud, exactly what this whole Act was for: turned one confusing incident into four separate, real, nameable problems — each one pointing at a specific place data lives, not a vague sense that "something's wrong." That's the actual skill this Act built, and it's worth naming plainly before moving on.

  • The real diagnosis, chapter by chapter. The lost cart is a volatile-vs-persistent problem (chapter 2) — data that needed to survive a refresh and didn't. The slow page load is a latency problem (chapter 4) — a request paying a real, specific tier's cost. The missing images and stale prices are both very likely caching and storage-placement problems — exactly what Acts 4 and 5 exist to fix. None of these needed the word "database" once.
  • A real decision framework, in miniature. Choosing where any specific piece of data should live now has real, honest questions behind it: does it need to survive a restart (volatile vs. persistent)? How fast does it need to be reached (latency)? How much of it is there, and how fast is that growing (capacity)? Is it moved in bulk or accessed in many small, scattered operations (throughput vs. IOPS)? Which of the three real shapes — block, file, or object — actually fits its structure? Every later Act in this course adds real depth to one piece of this same framework.
  • What's actually coming next. Act 2 goes deep on the browser's own real storage options — cookies, localStorage, IndexedDB — and fixes the cart problem for real, not just diagnoses it. Act 3 goes deep on file systems — what a file actually is, underneath the folder icon. Act 4 goes deep on caching — the real, honest fix for stale prices and slow repeated requests. Act 5 goes deep on block and object storage — the real fix for images and any data outgrowing a single machine. Act 6 goes underneath every database this course has ever covered, to the storage engines they're all quietly built on. Act 7 closes the whole course by putting all of it together into one real storage architecture.

None of GreenMart's four original problems are actually fixed yet — that was never this Act's job. What changed is that all four are now real, specific, diagnosable questions instead of one confusing incident, and GreenMart has the real vocabulary to follow each one to its actual answer.

Key Takeaway

"Where should this data live?" was never answerable with a single word like "the database." It's answerable with a real, honest set of questions — durability, latency, capacity, access pattern, and shape — and this Act just handed GreenMart all five.

Why This Matters

Every real storage decision GreenMart makes from here forward — in this course and after it — benefits from the same real questions this Act built: does this need to survive a restart, how fast does it need to be reached, how much of it is there, how is it accessed, and what shape does it actually take. That's not a memorized list — it's the actual reasoning this whole Act walked through, live, on GreenMart's own real incident.

GreenMart closes this Act with real, working vocabulary for a problem that started as pure confusion — and a real map of exactly where the rest of this course is headed. Act 2 picks up the very first thread: the browser's own real storage, and the actual fix for GreenMart's lost carts.

Next