Multi-Model Checkpoint

Audit GreenMart's Database Sprawl

Reasoning Checkpoint

A design challenge, worked through in writing — no auto-grading, just a real attempt.

18–22 min

The Challenge

Four chapters of reasoning about GreenMart's own real database sprawl — Sarah now has to turn that reasoning into an actual, defensible audit, not just a general appreciation of the trade-offs.

You have GreenMart's real eight-system inventory in front of you: MongoDB (catalog), Redis (cache/sessions), DynamoDB (fleet tracking), Cassandra (sensor telemetry), a graph database (fraud detection), a search engine (product search), a vector database (shopping assistant), and a realtime sync layer (live order tracking). Write out Sarah's actual audit: one real pair worth consolidating, one system that should stay specialized, and the honest reasoning behind each call.

What Your Audit Needs

  • Explain, in your own words, why every one of GreenMart's eight databases being individually well-justified doesn't mean the total operational cost is acceptable — naming the specific cost this is (not just "it's a lot of systems").
  • Pick one real pair from GreenMart's inventory (not necessarily the catalog + search example already worked through in chapter 4) and make a genuine case for consolidating them onto a multi-model system — justified by a real, specific cross-model query need, not just "it would be simpler."
  • Pick one system from the inventory that should explicitly stay specialized, and justify it using this Act's own two-question framework: is it genuinely near a specialist's real performance ceiling, or does it lack any real cross-model query need with the rest of the inventory?
  • Name at least one real cost your proposed consolidation would accept in exchange — a specific transaction-boundary, performance, or vendor trade-off, not a vague acknowledgment that trade-offs exist.
Stuck? A Few Hints
  • Reread chapter 4's own worked example (MongoDB catalog + search engine) for the shape a real, well-justified consolidation case should take — yours can name a different pair, but the reasoning needs the same specificity.
  • "It would reduce the number of systems" is true of almost any pair and isn't, by itself, a real justification — the genuine question is whether that specific pair actually needs to be queried together.
  • Chapter 1's own inventory table already named who maintains each system and how — that's a real clue for where operational cost is concentrated, not just evenly spread across all eight.

Before You Move On

Notice what this checkpoint never asked: a rule that applies to all eight systems at once. That's deliberate — this Act's whole argument was that the decision is real and per-pair, not a single verdict for an entire inventory. The next Act moves past any one system's own design entirely, into what happens when the network between regions genuinely breaks and two places disagree about the truth at the same time.

Next