Challenge 2: ip_hash and a Disproportionate Traffic Concentration — Solution Walkthrough

The likely cause:

Per this chapter's own ip_hash section, this pattern is a classic sign
that a large number of distinct users are actually sharing a small
number of visible client IP addresses — most commonly because they're
behind a large corporate NAT gateway or a shared proxy. ip_hash routes
based on a hash of the client's IP address, so every one of those many
users behind the same shared IP gets hashed to the identical backend,
regardless of how many distinct individual users are actually
involved.

Why this isn't a sign of a broken hash function:

The hash itself is working exactly as designed — the same input (IP
address) reliably produces the same output (which backend). The
actual problem is that the input itself isn't as evenly distributed as
the company assumed: many real users mapping to only one or two
distinct IP addresses means ip_hash has no way to distinguish between
them, and correctly (from its own perspective) sends them all to the
same backend.

What this reveals about ip_hash's own trade-off:

This is precisely the limitation this chapter's own ip_hash section
names directly — an uneven distribution of client IP addresses (not
uneven actual load) produces uneven backend distribution, since
ip_hash has no visibility into how many real users sit behind a given
IP.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies this chapter's own named ip_hash trade-off to a
realistic symptom a team might actually observe, correctly tracing the
concentrated traffic back to shared client IPs rather than assuming a
bug in Nginx's own hashing logic.