Chapter 37 — Exercises

Apply the decision framework to scenarios. (answer in Appendix) = worked solution in Answers. ⭐ = stretch.

Group A — The framework

A1 (37.1) List the decision-framework factors and one question each answers. (answer in Appendix)

37.2 Why is the data's essential nature (model/shape) usually the biggest factor?

37.3 Why is "be honest about scale" emphasized? What mistake does it prevent?

Group B — Why PostgreSQL default

37.4 Justify "start with PostgreSQL" factor by factor (model, workload, scale, consistency, queries, ops, cost). (answer in Appendix)

37.5 Give two examples of PostgreSQL extensions covering a "specialized database" need (theme #4).

37.6 ⭐ When does a factor decisively rule out PostgreSQL? Give a concrete example.

Group C — Apply it

For each scenario, choose a primary database (and any justified additions) and justify via the framework.

37.7 A SaaS billing app (users, subscriptions, invoices). (answer in Appendix)

37.8 A real-time game leaderboard with millions of updates/sec.

37.9 Petabyte-scale clickstream analytics.

37.10 A document-search/AI-assistant feature over a help center.

37.11 ⭐ A social network needing "friends within 3 hops" recommendations.

Group D — Polyglot

37.12 What is polyglot persistence, and what's the discipline that keeps it healthy vs. sprawl? (answer in Appendix)

37.13 ⭐ Design a justified multi-database architecture for a mid-size e-commerce app, naming each store and its concrete need (and the system of record).

Group E — Progressive project

37.14 Run the full framework for your project; state and justify your primary database choice factor by factor.

37.15 Identify any justified polyglot additions (with the concrete need / extension).

37.16 ⭐ Name the requirement change that would make you revisit your choice.

Self-check. If you can apply the framework to any scenario, default to PostgreSQL with justification, and design minimal justified polyglot — you can make sound database decisions. Next: operating it in production.