Reasoning Checkpoint
A design challenge, worked through in writing — no auto-grading, just a real attempt.
The Challenge
Six chapters of real, unifying frameworks — access-pattern-driven design, hot/warm/cold data, cost vs. performance, reliability — all converging on one last real challenge, deliberately a new one: GreenMart's own in-store self-checkout kiosks.
Each kiosk needs to look up live prices and stock, keep working through a spotty in-store WiFi connection, print and durably store real receipts, and log every real interaction for later analytics — a genuinely different challenge than the same-day-delivery example the previous chapter walked through. Run this whole course's own complete process yourself, start to finish: break it into its real data shapes, apply access-pattern-driven design to each, place each by its real temperature, and verify cost and reliability explicitly.
What Your Storage Architecture Needs
- Break the kiosk feature into at least four genuinely separate real data shapes (for example: live price/stock lookups, a local offline-resilient cache, printed receipts, and interaction event logs) — not one blob, reasoned from what each piece actually needs, not guessed.
- For each data shape, name its real access pattern (read/write ratio and volume, consistency needs, growth shape) using this course's own access-pattern-driven design framework.
- Assign each data shape a real hot/warm/cold temperature, and name the specific real mechanism from this course (a fast/cache tier, a standard database or object storage tier, or a lifecycle-managed cold tier) that actually fits it.
- Explain how the kiosk should keep working through a spotty or dropped in-store WiFi connection, using this course's own real offline-first vocabulary (from the browser storage Act) — even though a kiosk isn't a browser, the same real principle applies to any local, disconnected-capable device.
- Name the real storage engine family (B-tree or LSM tree) that best fits the kiosk's own interaction event log, and justify it using this course's own read/write-pattern reasoning — not by habit or familiarity.
- State Sarah's final architecture in one real, defensible paragraph — naming each data shape's placement and the one specific requirement it answers — then separately name one real reliability guarantee (crash consistency, durability, or recoverability) this specific architecture still needs to explicitly verify, not just assume.
Stuck? A Few Hints
- Reread this Act's own "Designing a Storage Architecture" chapter's four-step process — the exact same four steps apply here, just to a genuinely different feature.
- The receipt is a real, legally-relevant document, written once and read rarely after the transaction — which earlier Act's own storage model was built precisely for that shape?
- "Spotty WiFi" is the same real problem this course's own browser-storage Act solved for a different device — a real, local cache-first strategy, with a background sync mechanism for anything that couldn't complete while offline.
- The interaction event log is high-volume and append-style, generated constantly by every kiosk in every store — which storage engine family from this course's own Act 6 is built specifically for that real write pattern?
Before You Move On
That's the whole of Storage Systems, in one final architecture — and, honestly, the whole three-course journey behind it. Not a longer list of technology names, but the real, repeatable habit of naming what data actually needs — how it's read, how it's written, how it ages, what it costs to lose — before reaching for anything familiar. From a single database's own first table to a real, multi-layer architecture spanning caches, file systems, object storage, and storage engines: GreenMart — and you — now have the real, complete habit for good.