In this chapter
We'll run this whole course's own frameworks together, in order, against GreenMart's real same-day delivery feature — breaking it into its genuinely different real data shapes, applying access-pattern-driven design and hot/warm/cold placement to each, then verifying cost and reliability explicitly — the complete, real process every future storage decision will now follow.
The Problem in Real Life
GreenMart's next real expansion is finally on the table: same-day delivery, with live driver tracking. Sarah turns to Mike. "This is the real test," she says. "Not a one-off decision made under pressure — the full process, start to finish, before a single line of code gets written."
Mike nods. "Walk me through it. All of it, this time."
Walk me through the whole real process this time — not another one-off decision.
Mike
A Decision Made Under Pressure vs. A Real, Complete Process
One feature, several real data shapes
Same-day delivery tracking isn't one kind of data — live location, order status, and photos each need a genuinely different real home.
The complete, ordered real process
Break into data shapes, apply access-pattern design, place by temperature, verify cost and reliability — every step, every time.
Designing a Storage Architecture
Designing a real storage architecture means running this whole course's own frameworks together, in order, against one real feature — not picking a familiar technology and hoping it fits, but naming the real requirements first and letting them decide.
- Step one — break the feature into its real, separate data shapes. Same-day delivery with live tracking isn't one kind of data — it's several, genuinely different ones wearing one feature name: a driver's live GPS location (updated every few seconds), the order's own status history (read by the customer and support), and a proof-of-delivery photo (written once at drop-off, rarely read again).
- Step two — apply access-pattern-driven design (this Act, chapter 2) to each piece separately. Live location: extremely high write frequency, short-lived, needs to be fast, doesn't need to survive forever. Order status: moderate read/write, needs real durability, needs to reflect the current state accurately. Proof-of-delivery photo: write-once, read-rarely, needs to be kept for a real, legally-relevant retention period.
- Step three — place each piece using hot/warm/cold (this Act, chapter 3). Live location is genuinely hot — a cache or an in-memory store, not a database at all, with a real, short TTL. Order status is warm — the existing relational database or Cassandra cluster, whichever's own real write pattern actually fits. The photo is cold from the moment it's written — object storage, with a real lifecycle policy transitioning it to cheaper storage after the order's own active window closes.
- Step four — check cost versus performance and reliability (this Act, chapters 4-5) before committing. Does the live-location cache's real cost match its real, short-lived value? Does the proof-of-delivery photo have real, explicit durability — multiple physically-separated copies, since it may be a real, legal record? Nothing gets built until each real question has an honest, explicit answer, not an assumed one.
| Data | Access Pattern | Temperature | Real Placement |
|---|---|---|---|
| Live driver location | Extremely high write frequency, short-lived | Hot | Cache/in-memory store, short TTL |
| Order status | Moderate read/write, needs durability | Warm | Existing relational DB or Cassandra, by write pattern |
| Proof-of-delivery photo | Write-once, read-rarely, legally relevant | Cold (from day one) | Object storage + lifecycle policy |
One feature name, three genuinely different real data shapes, each placed by running this Act's own complete process — not one default technology applied to all three.
GreenMart now has the real, complete, worked example of this whole course's own process, applied start to finish — not a one-off decision made under pressure, but a deliberate, defensible architecture, built the exact same real, repeatable way for every future feature still to come.
Key Takeaway
Designing a real storage architecture means running this whole course's own frameworks — break the feature into its real data shapes, apply access-pattern-driven design to each, place each by its real temperature, then verify cost and reliability explicitly — as one complete, ordered process, not a single, familiar technology choice made once and hoped to fit everything.
Why This Matters
This is the exact real process GreenMart will run for every future feature, not just this specific delivery-tracking expansion — the actual, lasting skill this whole course exists to leave GreenMart with, worked live, start to finish, one real time.
GreenMart now has the complete, real, worked process for designing a storage architecture from scratch. It's time to run that exact same process, one more time, on a genuinely new real challenge: GreenMart's own capstone.