Challenge 3: The Real Risk ip_hash Doesn't Eliminate — Solution Walkthrough

The real risk:

Per this chapter's own warning box, if the specific backend holding a
client's session data (because ip_hash consistently routed that
client to it) goes down, that client's entire session is lost
outright — no other backend in the pool has any copy of that session
data to fall back on, since the session was only ever stored in that
one backend's own local memory. There is no failover for the session
itself, only for future requests being redirected to a different,
session-less backend.

Why a shared session store eliminates this risk:

If session data is stored in an externalized, shared store (such as
Redis) rather than in any individual backend's own memory, every
backend can read the same session data regardless of which one
happens to receive a given request. A backend going down no longer
destroys any session data at all, because the session was never tied
to that specific backend's own memory in the first place — any
surviving backend can pick up exactly where the failed one left off.

Why "just as reliable" is the wrong framing:

ip_hash only solves the routing-consistency half of the problem —
making sure the same client keeps reaching the same backend. It does
nothing to protect the session data itself from being lost if that
one backend fails. A shared session store solves the underlying
problem directly, removing the single point of failure ip_hash's own
approach still carries.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise directly applies this chapter's own warning box —
correctly identifying that the specific risk ip_hash doesn't address
is session data loss on backend failure, not merely "some inefficiency"
or a vague sense that a shared store is "better practice."