# Exercise 2 — Diagnose a Coupling Failure

## Scenario

A small startup built its order-processing system as a chain of direct synchronous HTTP calls:

```
Checkout Service --calls--> Inventory Service --calls--> Shipping Service --calls--> Notification Service
```

Each service calls the next one directly and waits for its response before replying to the one that called it. On a normal day this works fine. During a holiday sale, the Notification Service (which calls a third-party SMS provider) starts responding slowly — 8 seconds per request instead of 200ms — because the SMS provider is overloaded.

Within 15 minutes, the whole checkout flow is failing for every customer, not just the ones expecting an SMS.

## Deliverables

1. **Trace the failure.** Explain, step by step, exactly how a slowdown in the Notification Service (the last link in the chain) causes Checkout Service requests (the first link) to start failing. Be specific about what "waiting" does to each service in the chain — connection pools, thread/worker exhaustion, timeouts, whichever apply.

2. **Identify which of the four steps chained together (inventory reservation, shipping label creation, SMS notification, and whatever else you infer is happening in checkout) genuinely need a synchronous answer before checkout can respond to the customer, and which don't.** Justify each.

3. **Redesign with a broker.** Sketch the new architecture: which calls stay direct/synchronous, and which get replaced by publishing an event to a broker for asynchronous consumption. Name the event(s) and consumer(s).

4. **Re-run the failure scenario against your redesign.** With the SMS provider still slow, walk through what happens now. Does checkout still fail for customers? What (if anything) is still degraded, and for whom?

5. **Name the specific failure pattern.** The original design has a well-known name for "a slowdown in one downstream dependency cascades backward through a chain of synchronous callers." State the name and, in one sentence, why decoupling with a broker addresses it (a full defense against cascading failure — timeouts, circuit breakers, bulkheads — is broader than just adding a broker; this exercise focuses on the broker's specific contribution).

## Notes

- This exercise deliberately does not require code — reasoning about the failure mode and the redesign in prose/diagram form is the point.
- A hand-drawn (or ASCII) diagram of both the original and redesigned architecture is encouraged but not required.