Rate limiting lab
Run the rate limiting baseline
Production rule: Code and measure the normal path for a multi-tenant RAG answer API; no stage is complete until another operator can reproduce its evidence and reverse its risky action.
Before you start
Why this matters
In two minutes, write the user-visible outcome this page protects, one numerical threshold, and the first signal you expect to move. Then name an observation that would prove your initial theory wrong. Keep the answer beside your terminal; this lab rewards prediction before inspection rather than explanations invented after the graph changes.
1Learn the idea
Read
Lab target
You own a multi-tenant RAG answer API at POST /v1/answers. The goal is to protect shared model and vector-search capacity without punishing normal interactive users. The measurable target is a 60 requests/minute user bucket with a burst of 10, a 1,200 requests/minute tenant ceiling, and a 4,000 requests/minute global guard; rejected requests return HTTP 429 in under 25 ms with Retry-After. The known production tension is strict per-user fairness prevents a noisy neighbor but can block legitimate batch imports; local fallback buckets improve availability but permit bounded overshoot during Redis partitions.
Read
Implement one ordinary journey
Build the smallest normal path through POST /v1/answers for a multi-tenant RAG answer API. Use a fixed, non-sensitive fixture and assign a correlation identifier at ingress. The purpose is to establish known-good semantics before fault injection. For Rate limiting, the path must contribute directly to this goal: protect shared model and vector-search capacity without punishing normal interactive users. Avoid adding retries, fallback branches, or tuning until the baseline is observable.
Use the reviewed configuration:
limits:
user: { rate_per_minute: 60, burst: 10 }
tenant: { rate_per_minute: 1200, burst: 100 }
global: { rate_per_minute: 4000, burst: 250 }
backend:
redis_timeout_ms: 40
on_timeout: local_bucket
response:
status: 429
retry_after: true
Run the baseline command:
for i in $(seq 1 12); do curl -s -o /dev/null -w '%{http_code} %{time_total}\n' \
-H 'X-Tenant: acme' -H 'Authorization: Bearer user-42' \
http://localhost:8080/v1/answers; done
Record response status or operator state, important headers or fields, elapsed time, and side effects. Follow the same correlation identifier through structured logs. If the system is asynchronous, capture enqueue time, start time, completion time, retry count, and durable checkpoint. Run at least five samples so one warm cache or connection setup does not masquerade as normal behavior.
Read
Reconcile behavior with telemetry
The acceptance target is a 60 requests/minute user bucket with a burst of 10, a 1,200 requests/minute tenant ceiling, and a 4,000 requests/minute global guard; rejected requests return HTTP 429 in under 25 ms with Retry-After. Query rate_limit_decisions_total{scope,outcome}, rate_limit_redis_seconds, http_requests_total{status="429"}, and allowed request p95 latency immediately before and after the baseline. Calculate deltas rather than trusting dashboard shape. Every successful user event should map to a defined outcome counter; every duration should have a clearly named clock boundary. Confirm version and environment dimensions let an operator distinguish old and new code without adding customer-specific cardinality.
Write an expected event sequence before looking at logs. Compare it to the observed sequence and explain every extra event, especially hidden retries or duplicate processing. A successful response with unexpected retries is operational debt because it consumes capacity and predicts a sharper failure under load. Verify that logs contain reason codes and correlation IDs but not request bodies, credentials, or private document content.
Read
Establish the baseline envelope
Vary one legitimate input dimension—request size, tenant class, queue age, or dependency latency—and keep the rest fixed. Identify where the normal path approaches the target. Save p50, p95, and maximum for a bounded sample, plus demand and saturation. The baseline is invalid if traffic count is missing.
Use the historical failure as a warning: tenant acme-importer shipped a zero-jitter retry loop, consumed 74% of the global model budget, and pushed interactive p95 from 1.8 s to 6.4 s. Explain which normal-path measurement would have made that incident easier to recognize. Also record the production tension: strict per-user fairness prevents a noisy neighbor but can block legitimate batch imports; local fallback buckets improve availability but permit bounded overshoot during Redis partitions. The baseline page passes when another engineer can reproduce the journey and predict which telemetry changes before running it.