# Exercise 1: Diagnose Why Horizontal Scaling Didn't Help

## Scenario

`QuizWave`, a live-trivia app, runs its API tier on a single stateful server that holds each active quiz session's in-memory state (current question, scores, connected players) in a plain JavaScript object keyed by session ID. Under load during a popular live event, the team's fix was to "just scale horizontally" — they put 4 identical instances behind a round-robin load balancer, expecting 4x capacity.

Instead, the event was WORSE than before: players got randomly disconnected, saw wrong/stale scores, and sometimes couldn't submit an answer at all. Support tickets included things like "my score reset to zero mid-game" and "the question changed for me but not my friend, we're in the same quiz."

## Deliverables

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

1. **Explain exactly why adding 4 instances made things WORSE, not just "didn't help"** — trace a concrete sequence of 2-3 requests from the same player hitting different instances (per the round-robin load balancer) and show precisely what breaks at each step, referencing theory Section 2's stateful-vs-stateless code example.
2. **Redesign the session-state storage** so the same 4 (or more) instances can be safely load-balanced — name the specific storage mechanism you'd move quiz session state into, and describe what changes in the API server's code (conceptually, not full code) to read/write session state from there instead of an in-memory object.
3. **Explain why your redesign in Deliverable 2 is now safe to scale horizontally**, explicitly connecting back to theory Section 2's definition of statelessness — what does "any instance can handle any request" now actually mean for QuizWave specifically?
4. **Identify one thing that does NOT automatically get fixed just by making the API tier stateless** — using theory Sections 3-4, name a part of QuizWave's system (think about what a live quiz session's real-time updates, like a question changing for every player at once, would need) that still needs its OWN scaling consideration even after the API tier itself is stateless.