# Exercise 2: The Distributed Monolith Diagnosis

## Scenario

A startup called Ferra split its product into 9 microservices 18 months ago, following advice that "microservices scale better." Today:

- Every deploy of `user-service` requires `billing-service`, `notification-service`, and `analytics-service` to deploy in the same release window, because they all depend on a shared internal npm package that changes with `user-service`'s API.
- Three of the nine services share the same PostgreSQL database instance (different schemas, but foreign keys across schemas).
- A single "place order" user action fans out to 6 of the 9 services synchronously, over HTTP, before the user sees a response.
- The on-call engineer, when `orders` is slow, has to check dashboards for 5 different services to find the actual bottleneck.
- There are 7 engineers total, organized as one team that works across all 9 services.

## Your Task

### Deliverables

1. **Diagnosis.** State plainly whether Ferra has a working microservices architecture or a distributed monolith, and back it with three specific pieces of evidence from the scenario — cite the theory file's definitions of what microservices are supposed to provide (independent deployment, fault isolation, independent scaling) and show which of those properties Ferra does *not* actually have despite running 9 processes.
2. **Root cause.** For each of the three symptoms below, name the specific mistake from the theory's "Why Microservices Are Not Free" / "Common Pitfalls" sections that caused it:
   - Coordinated deploys across 4 services
   - Cross-schema foreign keys shared across services
   - 6-service synchronous fan-out on the checkout path
3. **Remediation direction.** For just the synchronous 6-service fan-out problem, propose which later topic in this fundamentals group would directly address it (name the topic and, in one sentence, why), without designing the full solution.
4. **A counterfactual.** Given that Ferra has 7 engineers on 1 team, argue whether a modular monolith would have been a better starting point than 9 services — reference the Decision Guide table from the theory file explicitly (team size, domain understanding, ops maturity) in your answer.