Reasoning Checkpoint
A design challenge, worked through in writing — no auto-grading, just a real attempt.
The Challenge
Six chapters of reasoning, no code yet — that's on purpose. Before GreenMart touches a single new database, Sarah needs a real, defensible answer to one question: what should actually change, and why?
You have three real seller listings in front of you — an electronics charger, a clothing item, and fresh produce — plus everything GreenMart already runs on: Customers, Products, Sales. Write out Sarah's actual diagnosis: which of it should move to a NoSQL model, which of it should stay exactly where it is, and the real reasoning behind each call — not just "NoSQL sounds more flexible."
What Your Diagnosis Needs
- Explain, in your own words, why forcing electronics/clothing/produce listings into one shared relational table produces the sparse, mostly-empty rows from chapter 1.
- Decide whether the seller listings should move to a NoSQL model — and if so, name which of the four models (Document, Key-Value, Wide-Column, Graph) actually fits, justified by the real access pattern, not just "it's flexible."
- Using the CAP theorem, explain what trade-off GreenMart accepts by favoring Availability (eventual consistency) for seller listings specifically — and why that trade-off is actually acceptable for this data.
- Explicitly justify why Customers, Products, and Sales should stay exactly where they are, tying the answer back to polyglot persistence — not "because NoSQL can't do it," but the real, specific reason this data doesn't need what NoSQL trades for.
Stuck? A Few Hints
- Reread chapter 3's read-heavy vs. write-heavy idea — how often does a listing get viewed, compared to how often it gets edited?
- The right model isn't the most flexible one available. It's the one that matches how this specific data will actually be asked for.
- Chapter 6 already worked through the Orders half of this reasoning in detail — the seller-listing half is what's genuinely left for you to work out.
Before You Move On
Notice what this checkpoint never asked: which specific database to use, or what its query syntax looks like. That's deliberate — Act 1 was entirely about the design reasoning, not memorized product names. The next Act picks up exactly where this checkpoint leaves off: turning "Document model, chosen for these reasons" into a real, working database.