# Exercise 1: Design the Reverse Proxy Routing for a Multi-Service Platform

## Scenario

`northwind.dev` runs three independently deployed services that all need to sit behind one public domain and one TLS certificate:

- A server-rendered marketing/web app, currently listening on `10.0.0.20:3000`, serving everything at the root path.
- A REST API, currently listening on two load-balanced instances, `10.0.0.11:4000` and `10.0.0.12:4000`, that should be reachable under `/api/`.
- A real-time order-tracking service that uses WebSockets, listening on `10.0.0.30:5000`, that should be reachable under `/ws/`.

Additionally:

- All public traffic arrives as HTTPS; TLS should terminate at the reverse proxy, with plain HTTP used to reach the backends over the internal network.
- The API backend needs to know the original client's IP address for its per-IP rate limiter, and needs to know the original request was HTTPS (some of its code generates absolute URLs and must not emit `http://` links).
- The WebSocket service breaks silently (connections just never upgrade) if the necessary handshake headers aren't forwarded.

## Deliverables

Produce all of the following, in this file, below this line:

1. **An nginx-style reverse proxy config** (in the style of theory section 2's example) implementing path-based routing for all three services, with load balancing across the API's two instances.
2. **A complete list of every header you add or forward at each `location` block, with justification** — for the API location specifically, name each header from theory section 4 you must forward and explain what breaks for the backend if that specific header is missing.
3. **The additional directives needed for the `/ws/` location to support the WebSocket upgrade handshake**, referencing theory section 6's note on `Upgrade`/`Connection` headers, and one sentence on why ordinary HTTP testing of that route would not have caught a missing configuration here.
4. **A one-paragraph explanation of why TLS termination at the proxy plus `X-Forwarded-Proto` together solve the "absolute URL" problem described in the scenario**, referencing theory section 4.

## Constraints

- Every backend address used must match the scenario exactly (no invented IPs or ports).
- The config must route `/api/*` and `/ws/*` to their respective backends and everything else to the web app backend, matching theory section 6's API gateway pattern.
- Do not propose moving TLS termination to the backends — it must stay at the proxy, per the scenario.