In this chapter
We'll turn all seven of this Act's real mechanisms — cookies, localStorage, sessionStorage, IndexedDB, the Cache API, Service Workers, and offline-first patterns — into one real decision framework, and close with the actual, final fix for GreenMart's own lost shopping cart.
The Problem in Real Life
Sarah steps back from a whiteboard that's now genuinely full — seven real mechanisms, each with its own real trade-off. "We started this Act with one lost cart," she says. "We're closing it with an actual decision about where every kind of GreenMart's browser-side data should really live."
Mike looks at the board, then at the original incident screen, still open in another tab. For the first time, it looks less like a mystery and more like a checklist.
We've got seven real tools now. Which one actually fixes the cart?
Mike
Seven Real Mechanisms vs. One Real Decision
A real, repeatable framework, not a memorized list
Server-visibility, restart-survival, structure, and offline needs — the same four real questions decide every browser-storage choice.
The cart problem, finally actually fixed
sessionStorage, written explicitly on every change — a real, deliberate fix, not a guess, closing the loop this whole Act opened with.
Choosing Browser Storage
Every mechanism this Act covered answers a genuinely different real question. Choosing between them isn't about which is "best" — it's about matching each specific kind of data to the mechanism actually built for its real shape and real needs.
- The real questions that decide it. Does the server need to see this automatically on every request (favors a cookie), or does only the page need it (favors everything else)? Should it survive a full browser restart (localStorage, IndexedDB) or just the current tab (sessionStorage)? Is it simple key-value data (localStorage/sessionStorage) or real structured, queryable data at scale (IndexedDB)? Is it application data (IndexedDB) or a cached network response (Cache API)? Does it need to work with zero connectivity at all (Cache API + Service Worker)?
- The real, final fix for GreenMart's cart. A cart is page-side data (the server doesn't need it on every image request), simple enough in shape for a key-value store, and — per Mike's own real answer, back in the sessionStorage chapter — probably shouldn't survive a full browser restart, since prices and stock can change by the time someone returns. The honest, real fix: sessionStorage, written to explicitly on every cart change, instead of relying on in-memory state a refresh silently erases. If GreenMart later decides a cart should survive a restart, the fix is the same shape, just localStorage instead — a real, deliberate product decision either way, not an accident.
- The real fix for the other three original problems. Missing images and stale prices point at real caching decisions (Act 4 goes deep here) and, for images specifically, the Cache API and Service Worker mechanisms this Act just covered. The slow page load points at real latency (Act 1's own subject) compounded by whatever's actually being fetched fresh instead of served from a well-chosen cache.
| Real Question | Answer Favors |
|---|---|
| Does the server need this automatically, on every request? | Cookie |
| Simple key-value, should survive a full browser restart? | localStorage |
| Simple key-value, should NOT survive closing the tab? | sessionStorage |
| Real structured data, queryable, potentially large? | IndexedDB |
| A cached copy of a real network response (image, page, API call)? | Cache API |
| Needs to work with zero network connectivity at all? | Cache API + Service Worker together |
This is the same real decision GreenMart's own cart needed — matching the shape of the data to the mechanism actually built for it, not picking the first one that technically works.
GreenMart closes this Act having done, for real, what Act 1 only diagnosed: turned "the cart just disappeared" into a specific, deliberate, correct fix — and built the real, working mechanism for Mike's bigger idea, a genuinely offline-browsable storefront, along the way.
Key Takeaway
"Where should this browser-side data live" was never a coin flip between seven similar-sounding options — it's a real, small set of honest questions, and this Act just handed GreenMart all of them, proven against a real incident from start to finish.
Why This Matters
Every future feature GreenMart ships that touches the browser — a wishlist, a draft review, an offline mode for a new page — now has a real, repeatable decision process behind it, instead of reaching for whichever storage mechanism happens to be familiar.
GreenMart closes Act 2 with the cart problem actually fixed, and a real framework for every browser-storage decision still to come. Act 3 turns to the layer underneath all of this — not what a browser stores, but what a file actually is, underneath the folder icon every server, everywhere, quietly relies on.