Reasoning Checkpoint
A design challenge, worked through in writing — no auto-grading, just a real attempt.
The Challenge
Seven chapters of real decision-making, all converging on one last real challenge — GreenMart's actual next expansion, a different one this time: "GreenMart Recipes," a feature letting customers type what they want ("something quick and vegetarian for tonight") and get matched recipes plus the exact products to buy for them.
This isn't the fleet-and-order requirement the chapters just walked through — it's a new one, on purpose. Run the same four-step framework yourself, start to finish: name the real requirements, identify the real candidates, let the requirements decide, and state the reason in one honest sentence.
What Your Decision Needs
- Name the real workload requirements for GreenMart Recipes across at least four of this Act's own categories (data shape/access, consistency/latency, scale/geography, ops/team, or risk/longevity) — not guessed, reasoned from what the feature actually needs to do.
- Identify which of this course's databases are genuine candidates for the natural-language, "something quick and vegetarian" part of the query, and explain precisely why a plain keyword match (an exact-match database query) isn't enough on its own.
- Decide whether GreenMart Recipes needs one database or a polyglot combination — and if more than one, name each one's specific job, not just "we'll use a few databases to be safe."
- State Sarah's final decision in one real, defensible sentence: which database(s), and the specific named requirement each one answers — the same standard the decision-framework chapter itself was held to.
- Separately, name one real operational or team-expertise trade-off this specific decision creates for GreenMart, using this Act's own vocabulary (managed vs. self-managed, operational complexity, or team expertise).
Stuck? A Few Hints
- Reread the workload-analysis chapter's own opening move: write down what the data actually looks like and how it's actually queried before naming any database. "Something quick and vegetarian for tonight" is a real clue about the kind of matching this feature needs.
- The real-world-comparisons chapter's own Elasticsearch-vs-database-search and Vector-DB-vs-pgvector rows are the closest matches here — reread what each one is actually good at, and notice they answer genuinely different questions.
- The risk-and-longevity-requirements chapter's own polyglot-persistence idea is the right tool for the third requirement — a workload can honestly be two shapes wearing one feature name.
Before You Move On
That's the whole course, in one final decision: not a longer list of database names, but the real, repeatable habit of naming what a workload actually needs before reaching for anything familiar. Thirteen Acts, sixteen real technologies, and one real skill underneath all of it — GreenMart — and you — now have it for good.