Challenge 2: Burst Requests Slowing Down Instead of Failing — Solution Walkthrough

Why this happens:

Per this chapter's own material, the burst parameter allows requests
above the configured steady rate to be queued rather than immediately
rejected — but without the nodelay flag, those queued requests are
processed with an added delay rather than being handled right away.
This means a request within the burst allowance still ultimately
succeeds, but only after Nginx has held it briefly to bring the
effective rate back down toward the configured steady limit, which is
exactly the "succeeds, but noticeably slower" behavior the team is
observing.

Why this isn't a bug:

This is the actual, documented default behavior of burst without
nodelay — Nginx is deliberately smoothing out a short spike in traffic
by spacing out the excess requests over time, rather than outright
rejecting them the way a request beyond even the burst allowance
would be. The team's confusion comes from expecting rate limiting to
only ever produce an explicit rejection (a 503), when queuing with a
delay is an equally real, and quieter, outcome of the same mechanism.

The fix, if immediate rejection or immediate processing is preferred:

Adding nodelay to the limit_req directive would process burst
requests immediately rather than queuing them with a delay — trading
the smoothing behavior the team is currently seeing for either a
faster response or an outright 503 once the burst allowance itself is
exceeded.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies this chapter's own burst/nodelay distinction to
a realistic, confusing symptom, correctly identifying that a delayed-
but-successful response is the expected behavior of burst without
nodelay, not a malfunction.