Exercise 3: What Unequal-Speed Round Robin and Sticky Sessions Have in Common — Possible Solution
====================================================================

WHAT "EQUAL SHARE" ACTUALLY MEANS IN BOTH SCENARIOS
------------------------------
This chapter's own Round Robin finding: sending exactly one-third of
all requests to each of three servers is only fair if all three
servers can process requests at the same rate. Once one server is
genuinely slower (capacity 2/tick vs. 5/tick), an equal SHARE OF
REQUESTS stops being an equal SHARE OF WORK - the slow server was
handed the same number of requests as the fast ones, but each of
those requests represents a larger fraction of its own limited
capacity.

This chapter's own sticky-session finding: hashing 30 session IDs
across 3 servers gives each client an equal, independent CHANCE of
landing on any given server - but chance isn't the same as balance.
With only 30 clients, hash luck alone produced a 60/65/25 split - not
because any client was treated unfairly, but because "everyone has an
equal probability" doesn't guarantee "the outcome is actually even,"
especially with a relatively small number of clients.

THE SHARED UNDERLYING MISTAKE
------------------------------
Both Round Robin and sticky-session hashing make their routing
decision using information that's fixed IN ADVANCE - Round Robin uses
a server's position in a rotating list; sticky hashing uses a hash of
the session ID - and neither one ever looks at what's actually
happening on the servers RIGHT NOW. "Equal treatment by some
predetermined rule" and "actually balanced outcome" are only the same
thing under a specific hidden assumption (equal server speed for
Round Robin; a large enough sample size for hashing to average out for
sticky sessions) - and this chapter verified both assumptions failing
in a real, measured way.

WHY "ROUTE BASED ON CURRENT STATE" FIXES BOTH
------------------------------
Least Connections doesn't decide in advance at all - it checks each
server's own CURRENT queue depth at the moment of every single routing
decision, and sends the new request wherever there's genuinely the
most room right now. This is why it kept the slow server's queue at 3
instead of 40 in this chapter's own first scenario, and why it
produced a perfectly even 50/50/50 split instead of 60/65/25 in the
sticky-session comparison: it responds to the actual, current state of
the system, rather than committing to a decision (a rotation position,
a session's own hash) that was made before the routing decision was
ever needed and can't adapt afterward.

WHY THIS WORKS AS AN ANSWER
------------------------------
The answer identifies the specific hidden assumption each "equal
treatment" rule relies on (equal server speed; large sample size),
shows both assumptions failing using this chapter's own verified
numbers, and explains Least Connections' own fix in terms of WHEN it
gathers its information (at the moment of the decision, not before)
rather than just asserting it's "smarter."