Rate Limiter (Token Bucket + Sliding Window + Leaky Bucket)

Add request-ID correlation

Every minute spent by support or on-call trying to figure out which server-side log line matches this customer's complaint is a minute the customer is waiting for an answer, and a minute of engineering time spent on detective work instead of a fix. Without request-ID correlation, that matching is done by eyeballing timestamps and hoping nothing else happened in the same window -- it gets actively worse as traffic grows, right when you can least afford slow incident response. This is usually one of the first things a customer-facing API is missing before it's ready to handle real support load, and it directly affects how fast SLA-bound issues get resolved.

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

Rate limiting exists to protect the business from abuse -- credential stuffing on login, scraping, or 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. Concretely: the login-brute-force-guard rule becomes decorative and any IP-based abuse mitigation elsewhere in the product inherits the same hole. This is a security control that looks like it's working (metrics show denials happening, dashboards look normal) while silently protecting against nothing for anyone who bothers to read the header-splitting logic -- exactly the kind of gap that shows up in a security audit or, worse, in an incident postmortem.

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

"A customer got wrongly throttled" is a routine support request, not an edge case -- shared office IPs, a customer's own retry storm, a bug on their 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, a blast-radius mismatch nobody should accept just to unblock one account). Every minute that customer is stuck is a minute of them unable to use the product, and every restart-as-a-fix is itself a minor self-inflicted incident. 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 (e.g. free-tier: 10 requests/minute) 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 -- costs that the pricing model assumed would be limited are not, and paying customers on higher tiers get no differentiated value from the tier they're paying for. 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 over time.

Omitting "n" in /api/v1/check now returns 500

This breaks the single most common call shape of the service's primary API -- every documented example, and almost certainly every real integration, omits n. Shipping this turns on an immediate, broad outage of /api/v1/check for essentially all normal traffic (a 500, not a graceful denial), the moment it reaches production. Any downstream service that depends on this endpoint for admission control would start failing closed or failing open depending on how it handles a 500 -- either way, an incident, not a degraded edge case.

Add decision-latency and build-info metrics

If the thing meant to protect your service's latency (the rate limiter) becomes the cause of latency -- a struggling Redis instance, say -- that should be visible and alertable well before customers notice. Without a per-decision latency metric, that degradation is invisible until it's already user-facing, turning a preventable, quietly-escalating problem into a customer-facing incident with no early warning. Build-info similarly matters operationally: during an incident, "did the fix actually deploy to this environment" is one of the first questions asked, and today there's no way to answer it from /metrics alone.

Redis sliding window disagrees with the in-memory one at window edges

This bug only manifests once you actually run the Redis backend -- i.e. the real, multi-instance production deployment shape, not local single-instance testing against the in-memory implementation. That's exactly the deployment most likely to matter most. With this live, a rule like free-tier (sold as "10 requests/minute") silently permits roughly double that at every window boundary, undermining the pricing/quota differentiation between tiers and removing the load-shedding protection any downstream system was sized around. It's also the kind of regression that passes every existing test (none of which exercise the Redis backend's edge timing) and would first be noticed in production, possibly during exactly the traffic spike the limiter exists to contain.

Add a composite (AND) limiter

Security- and abuse-sensitive endpoints (login, signup, checkout, password reset) routinely need protection along more than one dimension at once -- one bad IP, or one bad account, either alone shouldn't need to wait for the other to also misbehave before being throttled. Without a composable primitive, teams either ship weaker single-dimension protection (leaving a gap real abusers will find) or hand-roll bespoke multi-limiter logic per endpoint, which is slower to build, inconsistent across the codebase, and a larger surface for the exact kind of bugs this whole task list is about.

Token bucket admits more than capacity under concurrent load

A capacity guarantee that only holds under light load is not a capacity guarantee -- it fails precisely when traffic is heavy enough to matter, which is the entire reason a rate limiter exists in the first place. If a token bucket is sized to protect a downstream database, a paid third-party API with its own (billed) rate limit, or an expensive compute path, this bug means that protection quietly disappears under exactly the load spike it was provisioned for. That risk ranges from cascading internal outages to unexpected overage charges from a third party you're supposed to be shielding -- both are the kind of incident that happens once, expensively, under real production traffic, not in a quiet afternoon of manual testing.

Implement a fourth algorithm: fixed window counter

Not every product need justifies the sliding window's extra complexity -- some quota shapes (a daily export limit, a per-billing-period cap) are naturally and correctly expressed as a plain fixed window, and forcing every customer-facing quota through the sliding window's blending logic is more code, more to explain to customers who ask "how exactly does my limit work," and more surface for the class of bug in task 09. This ticket is also a direct test of the codebase's central design promise -- if it can't be done cleanly, that's a signal the abstraction underpinning every future rate-limiting feature needs rework before the product commits to more policies built on top of it.

Every denied request panics the Redis-backed token bucket

This is arguably the most severe item on this list: it crashes on the routine, expected outcome of rate limiting, not a rare edge case. On the Redis backend (the real multi-instance production deployment), the moment any customer actually reaches their limit -- which is supposed to produce a clean, well-understood 429 -- the request panics instead. That means your best, busiest, most-engaged customers (the ones who hit limits) are exactly the ones who experience this as broken/crashing behavior, likely with noisy error logs or process instability on every occurrence, the opposite of the graceful "please slow down" experience a rate limiter is supposed to provide.

Fall back to an in-memory limiter when Redis is down

Rate limiting is meant to be a best-effort protection, not a hard dependency for whether an endpoint works at all. As built today, a Redis blip -- routine infra maintenance, a network hiccup, a failover -- takes down every protected endpoint with a 500, converting a minor, expected infrastructure event into a full customer-facing outage. That's a much larger blast radius than the actual failure warrants, and it directly threatens uptime SLAs for something that should, worst case, only make rate limiting slightly less accurate for a few minutes.

Sliding window can deadlock permanently for a key

This is the hardest class of production incident to catch: one specific customer/key silently hangs forever, with no error, no alert, and every system-wide dashboard looking perfectly healthy. Support hears "your API just hangs for us" while on-call sees nothing wrong -- that mismatch alone can burn hours or days before anyone even suspects a single-key deadlock, let alone finds the exact oversized-request-during-rollover trigger. The cost isn't just the affected customer's downtime; it's the disproportionate engineering time spent diagnosing a bug that gives almost no observable signal to go on.