Exercise 3: Why Raising the Shared Limit Was the Wrong Fix — Possible Solution
====================================================================

WHY IT WAS THE WRONG FIX
------------------------------
Per this chapter, "this is genuinely not a capacity problem - the
limit was perfectly adequate for real traffic before this partner's
bug started firing." The per-key breakdown showed one specific key
(partner_x_7a92) responsible for over 87% of requests, while every
other legitimate client (mobile app users) consumed only a small,
normal fraction. Raising the shared limit would allow the misbehaving
partner to consume even more of the pool without addressing why it was
consuming so much in the first place - it treats the symptom (limit
being hit) rather than the cause (one client behaving abnormally).

WHY IT WOULDN'T ACTUALLY FIX THE UNDERLYING PROBLEM
------------------------------
The partner's retry logic, per this chapter, was "ignoring Retry-After
entirely" and "retries immediately on every 429, compounding the
problem with every failed attempt" (per Exercise 2's own reasoning,
this pattern gets worse, not better, over time). A higher limit would
only postpone when the partner's runaway retries next exhaust it -
the same underlying bug would eventually cause the same problem again,
just at a higher threshold, while also degrading service more broadly
for legitimate clients sharing the same pool in the meantime.

THE ACTUAL RESOLUTION
------------------------------
Per this chapter, "the honest resolution here is external: reaching
out to the partner to fix their retry behavior, and, in the meantime,
applying a tighter limit specifically scoped to that one key so it
stops degrading service for every other legitimate client sharing the
same overall pool." The fix targeted the specific misbehaving client
directly (a scoped, tighter limit for that one key) rather than the
shared pool overall, and acknowledged that a full fix required
external coordination with the partner, not just an internal
configuration change.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains specifically why the evidence (per-key breakdown) ruled out
a capacity explanation, why raising the shared limit wouldn't address
the actual misbehaving client, and correctly describes the two-part
resolution the chapter actually applied.