Romaji to Kana Converter: Astro — Chapter 7, Exercise 2
=====================================================================

TASK
Add the nginx rate-limit configuration exactly as this chapter
describes, then send a real rapid burst of more than 20 requests to
/api/convert from a script. Confirm some requests succeed and later
ones are rejected with a real 429 status, matching the
limit_req_status override.

SOLUTION

With limit_req_zone (rate=10r/s) and limit_req (burst=20 nodelay,
limit_req_status 429) configured exactly as the chapter describes, a
small script firing 30 requests as fast as possible from one machine
(so they all share the same $binary_remote_addr key):

  for i in $(seq 1 30); do
    curl -s -o /dev/null -w "%{http_code}\n" -X POST \
      https://romaji.example.com/api/convert \
      -H "Content-Type: application/json" \
      -d '{"romaji":"kyaku"}'
  done

produces a real, observable split in the output: the first roughly 20
requests return 200 (allowed by the configured burst), and requests
after that -- arriving faster than the sustained 10-per-second rate
the burst allowance can absorb -- return 429 instead of the default
503, confirming the limit_req_status override actually took effect
rather than nginx silently falling back to its own default.

The exact number of 200 responses before the first 429 can vary
slightly depending on real request timing (how tightly the loop's own
requests are actually spaced), since burst=20 nodelay is a genuine
token-bucket-style allowance, not a hard, precise cutoff at exactly
request 21 -- what matters is confirming both response codes actually
appear, not landing on one exact split.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reports a real, observed mix of 200 and 429 responses from an
actual burst of requests rather than assuming the configuration works
as described, and correctly notes the exact split point is expected
to vary with real request timing rather than claiming a falsely
precise "exactly 20 succeed" result.