Rate Limiter Service

Token bucket denies a request that exactly matches remaining tokens

Token bucket backs the pro-tier plan and any small-capacity policy (e.g. "1 password reset email per key at a time"). Losing the last unit of every configured burst means paying customers systematically get less throughput than the plan they bought -- worse for small capacities, where "capacity 1" effectively means "always denied." It shows up as support tickets from customers who have made zero real requests, and is easy to ship unnoticed because manual testing usually checks "does it deny eventually," not "does it admit exactly N."

Leaky bucket fills instead of draining

This algorithm guards login-brute-force-guard -- the login page, the single most trafficked, most first-impression-critical path in the product. A bug that turns a temporary slow-down into a permanent lockout means any legitimate user who ever tried logging in 5 times in a row (a mistyped password, a shared office IP) is locked out forever, with no recovery except an operator restarting the whole service -- which resets everyone's state, not just theirs. It reads to customers as "the login page is broken" and can look like a full outage even though every other system is healthy.

Add request-ID correlation

Every minute spent by support or on-call figuring out which server-side log line matches this customer's complaint is a minute the customer waits for an answer. Without request-ID correlation, that matching is done by eyeballing timestamps and hoping nothing else happened in the same window -- it gets worse as traffic grows, right when you can least afford slow incident response.

X-Forwarded-For trusts the wrong (spoofable) hop

Rate limiting exists to protect the business from abuse -- credential stuffing, scraping, a single bad actor consuming disproportionate infrastructure cost. A key-derivation bug that lets an attacker pick a fresh "identity" per request defeats that protection entirely for every rule keyed by IP. This is a security control that looks like it's working (dashboards look normal, denials happen) while silently protecting against nothing -- exactly the kind of gap that shows up in a security audit or an incident postmortem.

Add an admin endpoint to reset a key's limiter state

"A customer got wrongly throttled" is a routine support request -- shared office IPs, a retry storm, a bug on the customer's side that looked like abuse from ours. Today the only remediation is "wait it out" or "restart the service" (which resets every customer's state, not just theirs). An operator-facing reset endpoint turns a multi-team escalation into a 30-second fix.

Janitor evicts active keys almost immediately

Rate-limit tiers are how the product enforces its pricing model and how infrastructure cost stays bounded under abuse. If configured state resets far more often than IDLE_TTL promises, free-tier usage stops being meaningfully capped. Because this bug produces more allowed traffic rather than errors, it is one of the quietest possible failures to notice -- nothing looks broken from the outside, the bill or the abuse just creeps up.