Exercise 1: Sticky Sessions' Fix and Its Genuine Cost — Possible Solution
====================================================================

WHAT STICKY SESSIONS SOLVE
------------------------------
Per this chapter, sticky sessions "configure the load balancer to
route every request from a given user consistently to the same
backend server, usually via a cookie identifying which server they
were first assigned to." Since the same server always handles a given
user's requests, that server's own local, per-server memory is
sufficient to hold their session - no shared infrastructure is needed
at all.

WHY IT SOLVES THE PROBLEM WITHOUT SHARED INFRASTRUCTURE
------------------------------
The underlying problem (per this chapter's opening) is that "if each
server only keeps sessions in its own local memory, a session exists
on exactly one server." Sticky sessions solve this not by making
sessions available everywhere, but by guaranteeing every request for a
given user always reaches the one server where their session actually
lives - sidestepping the problem rather than solving it in general.

THE GENUINE FAILURE MODE IT INTRODUCES
------------------------------
Per this chapter's warn-box, "every user stuck to a given server has
all of their session state living only there. If that one server goes
down, gets restarted, or is removed during a deployment or a scaling
event, every session assigned to it is lost simultaneously." The fix
that avoids needing shared infrastructure does so by making each
server a genuine single point of failure for every session currently
assigned to it.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the specific mechanism by which sticky sessions avoid
needing shared session storage, and explains the exact tradeoff this
introduces - concentrated risk on individual server failure - using
the chapter's own reasoning.