In this chapter
We'll map out every real storage system GreenMart actually uses today — relational database, Cassandra, Redis, browser storage, object storage, and the file system underneath all of it — and see that this isn't accidental sprawl, but the real, deliberate, mature outcome of matching each kind of data to the system genuinely built for it.
The Problem in Real Life
Sarah pulls up a real, honest inventory of everywhere GreenMart's data actually lives today: a relational database, a Cassandra cluster, Redis, the browser's own storage, a growing object storage bucket, a real file system underneath all of it. Mike counts them on his fingers. "That's... a lot of different systems for one storefront."
"It is," Sarah says. "And every single one of them is there for a real, specific reason — this Act is where we finally look at the whole map at once."
That's a lot of different storage systems for one storefront. Is that actually normal?
Mike
Accidental Sprawl vs. Deliberate, Real Specialization
Many systems, each a real, deliberate answer
Every storage system in GreenMart's own stack exists because of a specific, nameable real requirement — not by accident.
The real test: sprawl vs. specialization
The honest question isn't how many systems exist — it's whether a real, specific reason exists for each one.
One Application, Many Storage Systems
A single real application using many genuinely different storage systems isn't a sign of poor planning — it's the real, expected, mature outcome of matching each specific kind of data to the system actually built for its real shape, exactly the discipline this whole course franchise has practiced, one real decision at a time.
- GreenMart's own real map, named all at once. The relational database holds structured, relationship-heavy data needing real transactional guarantees. Cassandra absorbs high-volume, write-heavy event data. Redis serves data that needs to be genuinely fast and often short-lived. Browser storage keeps page-side state close to the customer. Object storage holds product images and receipts, unbounded and growing. A real file system underneath every server holds application code and active logs. Every one of these is a real, deliberate answer to a real, specific question this course franchise has already asked and answered.
- The real difference between sprawl and specialization. Accidental sprawl is data landing somewhere for no real reason — whatever was already running, or whatever a developer happened to be familiar with. Deliberate specialization is exactly what GreenMart has actually practiced across this whole course: naming a real requirement first (read/write pattern, consistency need, growth shape), then choosing the system genuinely built for it. The real test isn't "how many systems do we have" — it's "can we name the real, specific reason each one exists."
- Why this actually gets harder, not easier, as an application grows. Early on, one database can honestly cover most of a real application's needs. As real features multiply — a cart, an event log, a growing catalog of images, a cache layer — the honest shape of the data diverges faster than any single system can gracefully cover, which is precisely why GreenMart kept adding a new, deliberate system at each specific point of real strain across this whole course, rather than forcing every new need into whatever was already there.
- The real cost this Act exists to manage. Every additional real storage system is also additional real operational surface — something else to monitor, secure, back up, and reason about. This isn't a reason to avoid genuine specialization; it's the real, honest trade-off this Act's remaining chapters build a deliberate framework for, so every future storage decision GreenMart makes stays a deliberate, defensible one, not an accidental one.
GreenMart now has the whole real map laid out at once — not a chaotic sprawl, but a genuine, deliberate specialization, one real decision at a time, across this entire course franchise. The rest of this Act turns that map into a real, repeatable process for every future storage decision still to come.
Key Takeaway
An application using many genuinely different storage systems isn't sprawl — it's the real, mature outcome of deliberately matching each kind of data to the system built for its actual shape, and the honest test is always whether a specific, real reason exists for each one, not how many systems there happen to be.
Why This Matters
As GreenMart plans its next real expansion, understanding its own current storage map — and exactly why each piece exists — is what turns "which database should this new feature use" from a guess into a real, informed extension of a pattern GreenMart has already proven works.
GreenMart now has the full, real map of every storage system it actually uses, and the honest distinction between deliberate specialization and accidental sprawl. The next chapter turns that map into a real, repeatable framework: choosing storage by access pattern.