Central Redis is the standard answer and its costs must be stated. It adds a network round trip to every request, which for a 5 ms endpoint is 10% of your latency budget — so the limiter must be one round trip, not four. It makes a limiter key a hot key: a single enormous tenant's counter is one Redis key handled by one shard, and Module P-7 explains why you cannot spread it. And it couples your availability to Redis, which forces a decision you should make deliberately:

Fail open or fail closed when Redis is unreachable? Fail open (allow the request) keeps you serving during a Redis incident and removes your protection at the moment traffic is most likely to be abnormal. Fail closed (reject) turns a Redis outage into a total outage. The defensible position is per-motive: fail open for fairness and quota limiters, fail closed for abuse limiters on /login and password reset, and keep an in-process fallback limiter with a generous per-instance limit so failing open is not unlimited. Whichever you choose, choose it explicitly — the default in most libraries is fail open, silently.

---

Do It in One Round Trip, and Never INCR Without Guaranteeing the Expiry

The obvious Redis implementation contains a bug that produces a permanent lockout:

If the process is killed between the two commands — a deploy, an OOM kill, a reclaimed spot instance — the key exists with no TTL. It never resets. That client is rejected forever, and no amount of waiting helps. The symptom is one tenant reporting permanent 429s that no restart fixes, and the cause is invisible unless someone thinks to run TTL on the key.

Two commands are also two round trips, doubling the latency the limiter adds. Both problems have the same fix: make the whole decision one atomic server-side operation with a Lua script.

Three properties make this the version to ship. It is atomic, so concurrent requests for one key cannot both read the same token count. It is one round trip, so it costs one RTT rather than four. And the PEXPIRE is unconditional on every call, so there is no window in which a key can exist without a TTL — with the TTL set to the time it takes an idle bucket to refill completely, since after that the state is indistinguishable from a fresh bucket and can be discarded safely.

Two operational notes. Use EVALSHA with the script cached, not EVAL shipping the source on every request. And under Redis Cluster, all keys touched by one script must live on one node, so if you ever need a multi-key script use a hash tag — limit:{tenant42}:api and limit:{tenant42}:reports share a slot deliberately (Module P-7).

Why this matters in production: a limiter is on the hot path of every request, so its own failure modes are outages. The three that actually happen are the TTL-less key that locks a customer out permanently, the four-round-trip implementation that adds 2 ms of p50 to every request in the system, and the limiter that fails closed during an unrelated Redis blip and takes the whole API down with it. None of the three is about choosing the wrong algorithm.

---

What You Key On Decides Who Gets Punished

The identity you count against determines who bears the cost of a mistake, and the ordering is not a matter of taste.

API key or tenant ID, when you have one. It is stable, it maps to a contract and a plan, it survives a client changing networks, and it makes the limit a documented number rather than a surprise.

Authenticated user ID for user-facing APIs, so one user on a shared corporate network cannot exhaust the allowance of the four hundred colleagues behind the same egress address.

IP address only as a last resort, for unauthenticated traffic where nothing better exists — and with clear eyes about two problems. First, IPs are shared: carrier-grade NAT puts thousands of mobile users behind one address, and a corporate office or a university is one address for an entire building. A tight per-IP limit is an outage for a large customer. Second, IPv6 makes per-address limiting nearly useless because a single subscriber commonly has a /64 — 18 quintillion addresses to rotate through — so limit on the /64 prefix rather than the address.

And the trap that turns an IP limiter into no limiter at all:

X-Forwarded-For is an append-only list, and an attacker can prepend anything. Taking the leftmost value means the attacker chooses their own limiter key and can send a different one per request. The correct read is from the right, skipping exactly as many entries as you have trusted proxies:

Get the count wrong in the other direction and you key everything on your own load balancer's address, limiting all traffic globally as if it were one client. Both errors are silent. If you sit behind a CDN, prefer its verified header (CF-Connecting-IP, True-Client-IP) and verify the request actually came from the CDN's address range, or the header is as forgeable as the one it replaces.

For abuse prevention specifically, key on a combination and limit each: /login needs a per-account limit (stops distributed password spraying against one account), a per-IP limit (stops one host trying many accounts), and a global limit (stops a botnet doing both slowly). Any single dimension is bypassable by varying the other.

---

Counting Requests Assumes Requests Cost the Same, and They Do Not

A limit of 1,000 requests per minute treats a primary-key lookup and a twelve-month aggregation report as equivalent. Module P-8 made this point as the mechanism behind a specific outage: one tenant, entirely inside their rate limit, took the shared database down with expensive queries, because request count is a poor proxy for cost.

Two fixes, used together.

Weight the cost. Token bucket already supports it — a request takes cost tokens, not one. Publish a table:

For GraphQL the equivalent is query complexity analysis, and it is not optional — Module F-8's point that one GraphQL request can be arbitrarily expensive means a per-request limit is meaningless there. Compute a static cost from the query's depth, breadth and requested page sizes, reject queries above a ceiling, and charge the computed cost.

Limit concurrency, not just rate, for expensive work. This is the control teams reach for last and often need most. Little's Law (Module F-4) says concurrency = arrival rate × service time, so a rate limit only bounds resource usage if service time is bounded — and for a report that sometimes takes 200 ms and sometimes 90 seconds, it is not. A limit of "at most 2 concurrent exports per tenant" bounds the resource directly, and the tenant's own throughput self-adjusts to whatever their queries actually cost.

Note the TTL on the concurrency key. A finally block does not run when the process is killed, so every concurrency limiter needs a lease that expires — the identical lesson to Module P-16's expired idempotency claim, and the same failure if you skip it: a tenant permanently at their concurrency ceiling with nothing running.

This is also the correct place to enforce the per-tenant connection budget from Module P-8. A cap on concurrent database work per tenant, which rejects rather than queues, is what stops one tenant holding every connection in the pool while everyone else waits (Module P-4).

---

Quotas Are a Billing Construct and Need Different Storage

A rate limit and a quota look alike and have almost nothing in common operationally.

The consequence is that a quota counter cannot live only in Redis, for the reason Module P-16 gave about dedupe: an eviction or a failover loses writes, and here the lost writes are money. The workable design counts in Redis for the fast decision and treats an append-only usage table in Postgres as the record, aggregated periodically:

The temptation to skip this and keep a tenants.calls_this_month column that every request updates deserves an explicit warning: a single row updated on every request serialises all of that tenant's traffic on one row lock, and generates a dead tuple per update, which is Module F-13's bloat mechanism at maximum intensity. It is one of the few designs that is both a correctness bottleneck and a vacuum problem at once.

Two quota behaviours worth deciding in advance rather than during an incident: whether exceeding a quota blocks (hard limit, predictable cost, angry customer mid-launch) or bills as overage (soft limit, happy customer, occasional enormous invoice and a dispute); and whether the reset is calendar-aligned or anniversary-aligned, since calendar alignment means every tenant's quota resets at the same instant and Module P-12's thundering herd arrives at midnight on the first.

---

The Response Is Part of the Design, Because It Shapes the Retry

A limiter that rejects badly creates the load it was built to prevent. Three requirements.

Return 429 Too Many Requests, with Retry-After. Not 503 (which means you are broken, and instructs well-built clients to retry against another node), not 403 (which means never), not 400. 429 plus Retry-After tells a client exactly one thing — wait this long — and a client that obeys it stops guessing.

Publish the state on successful responses too. RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset on every response let a well-behaved client pace itself and slow down before it is rejected. This is genuinely in your interest: a client that can see it has 20 of 1,000 remaining spreads its work out, whereas a client discovering the limit only through rejections learns it by hammering you. Token bucket makes these values exact, which is a real argument for it. The cost is a small information leak — the numbers tell an attacker how much room they have — which matters for abuse limiters, so omit the headers there and return a bare 429.

Make rejection genuinely cheap. A 429 that goes through connection setup, authentication middleware, an ORM initialisation and a template render costs you nearly as much as serving the request, so the limiter has protected nothing. Reject as early in the stack as possible — at the CDN or gateway for abuse, in the first middleware for everything else, before any database access. And never log a full line per rejection: a client sending 50,000 rejected requests a second will fill a disk and cost more in log ingestion than the requests would have cost to serve, which is Module O-1's cardinality warning arriving from an unexpected direction.

A related client-side obligation, since you are also somebody's client: honour Retry-After instead of applying your own backoff curve on top of it, and keep a retry budget (Module A-6) so that a service returning 429 to everything does not receive three times the traffic as a result.

---

Layer the Limits, and Derive the Numbers From Measurement

Real systems run several limiters at once, each answering a different question:

Evaluate cheapest-first and reject on the first violation, so an abusive client is rejected by an in-memory or edge check rather than after five Redis round trips.

The last question is where the numbers come from, and the honest answer is that a limit invented in a design meeting is a guess. It should come from a load test that found the knee of your curve (Module O-5), minus headroom, divided across tenants by plan. A limit above your real capacity provides no protection and creates a contractual promise you cannot keep — which is worse than no limit, because customers build against it. A limit far below capacity throttles paying customers to protect capacity you are already funding (Module O-8). Both errors are found the same way: measure, then set the number, then re-measure after every significant change to what the endpoint does.

---

Where This Shows Up in Your Stack

• Redis: the canonical home for limiter state — small keys, extremely high write rate, no durability requirement, and EVALSHA giving you atomic multi-step logic in one round trip. Keep the whole decision in one script; never INCR then EXPIRE as two commands. Watch for the hot-key problem when one tenant's counter is enormous (Module P-7), use hash tags if a script must touch several keys under Cluster, and remember that maxmemory-policy matters: an allkeys-lru instance can evict a limiter key and silently reset a client's usage, so limiter state generally belongs on an instance with volatile-ttl or on its own database.
• PostgreSQL: the durable record for quotas, as an append-only usage_events table with a uniqueness constraint for dedupe (Module P-16), aggregated on a schedule. Never a single counter column updated per request — that serialises the tenant on one row lock and produces a dead tuple every time (Module F-13). Partition usage by month so closing a billing period and dropping old data are both metadata operations (Module P-9).
• Node.js: express-rate-limit and friends default to an in-memory store, so the deployed limit is your configured limit times your instance count — always configure the Redis store explicitly. Set app.set("trust proxy", n) to your actual proxy depth or req.ip is either attacker-controlled or globally identical. Because the event loop is single-threaded, a concurrency limiter also protects you from one tenant's heavy JSON serialisation blocking every other request on the instance.
• Nginx / CDN / API gateway: limit_req is a leaky bucket with an optional burst, and it is the cheapest possible rejection because it never reaches your application. Cloudflare, CloudFront and equivalents give you per-PoP counting — approximate globally, exact enough for abuse prevention, and free of any round trip. Put abuse limits here and business limits in the application, where the tenant and plan are known.
• Kafka: broker-side quotas throttle producer and consumer byte rates per client ID, which is the same fairness argument one layer down: without them, one misconfigured producer saturates the brokers and every consumer group's lag climbs (Module P-15).

---

Summary

• A limiter exists to make rejection cheaper than collapse. Past the knee of the curve, offered load does not plateau — accepted work slows, clients time out and retry, and throughput declines while load rises. One counter increment refuses the work you cannot do so the work you accept still completes.
• Rate limiting is policy; load shedding is reaction. A limiter enforces a number you published in advance; a shedder (Module A-8) drops work because of your current queue depth and latency. You need both, and a limiter set above your real capacity protects nothing.
• Fixed window permits 2× the limit across a boundary and synchronises every throttled client onto the same instant. Sliding log is exact but costs memory proportional to the limit per key. Sliding window counter is two integers and removes the boundary burst at the price of approximation. Token bucket is the only one that expresses sustained rate and burst allowance separately, and the only one that yields an exact Retry-After — at the cost that a burst of B is real and your capacity plan must survive it.
• An in-memory counter multiplies your limit by your instance count, and changes when you autoscale, so the effective limit becomes a function of your deployment rather than your policy. Central Redis is the default; it adds a round trip, creates hot keys for large tenants, and couples your availability to Redis — so decide fail-open versus fail-closed deliberately, per motive, with a generous in-process fallback so failing open is not unlimited.
• Never INCR then EXPIRE as two commands. A process killed between them leaves a key with no TTL and locks that client out permanently, with no symptom other than 429s that no restart clears. One Lua script, EVALSHA, expiry set unconditionally on every call, one round trip.
• Key on API key or user ID; use IP only as a last resort. CGNAT and corporate egress put thousands of users behind one address, IPv6 requires limiting the /64 prefix, and the leftmost X-Forwarded-For value is attacker-controlled — set your actual trusted-proxy depth, or verify your CDN's header and source range. Abuse limits need per-account and per-IP and global dimensions, because any single one is bypassable.
• Request count is a poor proxy for cost (Module P-8): weight expensive endpoints in token cost, compute query complexity for GraphQL, and for work of unbounded duration limit concurrency rather than rate — because Little's Law means a rate limit only bounds resources when service time is bounded. Concurrency permits need a TTL, or a killed process leaks one forever.
• Quotas are durable and rate limits are not. A quota appears on an invoice, so its record belongs in an append-only Postgres table with Redis as the fast path — never a single counter column updated per request, which serialises the tenant on a row lock and bloats the table at once.
• Reject with 429 and Retry-After, publish RateLimit-* headers on success so clients pace themselves before being rejected rather than discovering the limit by hammering you — omitting them on abuse limiters, where the numbers help an attacker. Make the rejection genuinely cheap and early, and never log a line per rejection or the log bill exceeds the cost of serving the traffic.
• Layer limits cheapest-first — global, per tenant, per endpoint, concurrency, abuse — and derive the numbers from a load test (Module O-5), not a design meeting. A limit above capacity is a promise you cannot keep; a limit far below it throttles customers to protect capacity you are already paying for.

The next module, Background Jobs and Scheduling, is where the work you accepted but did not do inline actually happens. Everything deferred so far — the webhook receiver's queue-then-ack, the export that needed a concurrency limit instead of a rate limit, the outbox relay — lands in a worker pool with its own retry policy, priority classes, and the cron job that fires twice on the same minute.

---