Challenge 3: The Trade-Off Sticky Sessions Introduce — Solution
Walkthrough

The problem sticky sessions solve:

A backend that keeps a client's session state in its own local memory
(rather than in some shared, external store) needs that same client's
future requests to keep landing on that exact same backend instance --
otherwise, a request that happens to land on a different member simply
won't find the session state it needs, and the user effectively gets
logged out or loses whatever state was being tracked mid-session.
Sticky sessions solve this by pinning each client to one specific
backend member for the duration of their session, using a cookie or
URL parameter to consistently route them back to it.

The real trade-off it introduces:

Pinning a client to one member works directly against genuine load
balancing. Traffic no longer distributes freely across the pool based
on current load or algorithm -- once a client is stuck to a member,
every one of their requests goes there regardless of whether that
member is busy or idle relative to the others. In a scenario with a
small number of very active clients, this can leave some pool members
overloaded while others sit comparatively idle, defeating much of the
point of having multiple backends in the first place.

An alternative that avoids needing sticky sessions:

Moving session state out of each backend's own local memory and into
a shared, external store that every backend member can read from and
write to -- Redis is a common real-world choice for this. Once session
state lives somewhere all members can access equally, any member can
handle any request from a given client and still find the right
session data, so there's no longer a reason to pin that client to one
specific backend at all -- true load balancing can be restored.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader understands sticky sessions as a
genuine trade-off (solving a real problem at a real cost), not a
purely beneficial feature, and can name a concrete architectural
alternative rather than treating "pin the client" as the only
possible solution to the underlying session-state problem.