# Exercise 1: Decompose (or Don't) — BrightCart

## Scenario

BrightCart is a mid-size e-commerce company running a single Node.js/Express monolith called `bright-api`, backed by one PostgreSQL database. Current modules inside the monolith:

- **Catalog** — product listings, search, categories. Read-heavy, ~10,000 requests/min at peak, almost no writes outside of a nightly supplier feed import.
- **Cart** — session-based shopping cart. Read/write balanced, ~2,000 requests/min.
- **Orders** — order placement, order history. Writes must be transactionally consistent with Inventory (an order can't be placed if stock isn't reserved in the same transaction).
- **Inventory** — stock counts per warehouse. Tightly coupled to Orders today (same DB transaction on every checkout).
- **Recommendations** — "customers also bought" ML-scored suggestions, recomputed nightly, served read-only, occasionally has slow queries that have caused full-app slowdowns twice this quarter.
- **Reviews** — customer product reviews and ratings, low traffic, rarely changes.

There are 14 engineers on one team today, but the company is hiring toward three teams: Catalog/Search, Checkout (Cart+Orders+Inventory), and Growth (Recommendations+Reviews).

## Your Task

Produce a decomposition plan. Do not just say "split everything into microservices" — justify each decision against the trade-offs from the theory file.

### Deliverables

1. **Extraction list, ranked.** For each of the six modules, state: extract now, extract later (and under what trigger condition), or keep in the monolith indefinitely. Justify each with a specific signal from the theory (scaling mismatch, team ownership boundary, fault isolation need, transactional coupling, etc.) — not a generic "microservices are more scalable."
2. **The Orders/Inventory problem.** Orders and Inventory currently share a DB transaction to guarantee no overselling. If you extract Inventory into its own service, name the specific consistency mechanism you'd need instead of a single ACID transaction (you may reference the Distributed Transactions or CAP Theorem topics by name even if you haven't studied them in depth yet — the point is to recognize this specific problem exists, not to design the fix here).
3. **The Recommendations incident.** Explain, using the Under the Hood section's model of function calls vs. network calls, exactly why a slow query inside Recommendations was able to slow down the entire monolith — and why extracting it into its own service would change that failure mode (or wouldn't, if you conclude it wouldn't — justify either way).
4. **A one-paragraph risk.** Name the single most likely way this decomposition plan could go wrong in practice (e.g., producing a distributed monolith) and the concrete symptom that would reveal it happened.

There is no single correct extraction list — grade your own answer against whether every decision cites a real trade-off from the theory file rather than a general preference for one architecture.