In this chapter
We'll draw the real line between volatile storage (gone on restart, chosen for speed) and persistent storage (survives on purpose, at a real cost) — and use it to explain exactly what happened to GreenMart's lost shopping carts.
The Problem in Real Life
Sarah pulls up the cart-loss ticket again. A customer adds three items, switches tabs to compare a competitor's price, comes back, refreshes — and the cart is empty.
"That's not a bug exactly," Sarah says. "That's what happens when data was never asked to survive a restart in the first place."
The cart wasn't lost. It just never agreed to still be there.
Sarah
What Survives a Restart, and What Doesn't
Volatile storage is fast, and gone on restart
RAM, and anything built purely on it, trades durability for real speed — a deliberate trade, not a flaw.
Persistence is a deliberate cost, not a default
Surviving a restart requires someone to actually choose it — GreenMart's lost cart is what happens when nobody did.
Volatile vs. Persistent Storage
Every real storage decision starts with one honest question: if the power cuts out or the process restarts right now, does this specific piece of data survive? The answer splits all storage into exactly two categories.
- Volatile storage loses its contents the moment power is cut or the process restarts. RAM — the memory a running program uses — is the classic example. It's not a flaw; it's a trade, made on purpose, for real speed (Act 1's own next chapter, the memory hierarchy, explains exactly why). A browser tab holding a cart in its own in-memory JavaScript state, never written anywhere durable, is volatile in exactly this sense — a page refresh restarts that memory, and the cart goes with it.
- Persistent storage keeps its contents across a restart, on purpose — a hard disk, an SSD, or a real durable browser API (Act 2 covers several) all qualify. Persistence isn't automatic or free; something specific has to write the data somewhere durable, and that write itself costs real time compared to just holding a value in memory.
- The actual trade being made. Nothing is persistent by default — persistence is always a deliberate choice to pay a real cost (slower writes, more complexity) in exchange for surviving a restart. GreenMart's cart problem is exactly this choice made invisibly: whatever held the cart before the refresh was treated as good enough without anyone deciding, on purpose, whether it needed to survive one.
This is the same real distinction that shows up everywhere in this course, in a new place each time: RAM vs. disk in the memory hierarchy, a browser's in-memory variable vs. localStorage, a cache's fast copy vs. the real record it's a copy of. Naming it once, clearly, here, is what makes it recognizable everywhere else it shows up.
Key Takeaway
Nothing survives a restart by accident — persistence is a real, deliberate cost someone chose to pay, or forgot to. GreenMart's lost cart is the second kind: a real decision nobody actually made.
Why This Matters
"Should this survive a restart?" is a question every single piece of data in GreenMart's systems deserves a real, deliberate answer to — a shopping cart, a session, a draft order, a log line. Getting this wrong silently, the way the cart problem did, is exactly how a real feature quietly breaks without anyone deciding it should.
GreenMart now has real, precise vocabulary for the cart problem: it lived in volatile storage that was never asked to become persistent. The next chapter zooms out from this one binary choice to the full range of options between "instantly gone" and "reliably permanent" — the memory hierarchy.