hard Multi-Region Rate Limiting

Multi-Region Rate Limiting — a globally-shared quota under partition

Once a gateway is deployed in multiple regions with geo-routing, a per-client rate limit stops being a local counter and becomes a distributed-consensus problem: if each region keeps its own counter, a client with a "100/min" limit simply hits every region and gets 100/min per region. The whole design question is the consistency of the shared quota — and PACELC is the lens: a strictly-global count costs cross-region latency (and availability under partition), while per-region local counts are fast and available but only approximate globally.

The exploit to close

Limit = 100/min, three regions (US/EU/APAC), each enforcing its own 100 → a distributed client fans out across all three for 300/min. Any design that treats regions as independent counters has this hole.

Four stances (and the PACELC each takes)

• A — Strict global counter: every decision reads/writes one global store (or a quorum). Exact, no exploit — but adds a cross-region round-trip (~100 ms) to every limited request, and under partition it must stall or reject to stay exact. PACELC: PC / EC (consistency over availability and latency).
• B — Per-region hard split: give each region limit / regions (≈33 each). No cross-region exploit and no sync needed — but it wastes headroom (a user busy in one region is throttled at 33 while other regions sit idle) and rejects legitimate single-region bursts.
• C — Async-reconciled global (soft): each region decides locally against its own view and gossips/flushes counts to a global aggregate every ~1 s. Fast (local decision) and partition-tolerant, but approximate — a client can overshoot the global limit within the reconciliation window. PACELC: PA / EL.
• D — Client→region affinity: pin each client to one home region (by geo or consistent hashing) so its counter is local and exact with no cross-region sync at all. The cross-region exploit vanishes because the client only ever counts in one place. Cost: you need failover (re-home on region loss), and a client that legitimately roams regions is re-homed.

Judgment layer — when each

• Default (normal API quotas): C or D — availability and latency matter more than an exact count; a briefly-loose limit is acceptable. D is elegant when clients have a natural home region.
• Contractual / billing caps (a hard "10,000 calls/month you are billed for"): A — the count must be exact even at latency/availability cost; approximate over-admission would be revenue loss or abuse.
• B is the simplest and is fine when traffic is evenly geo-distributed and burstiness is low, but its wasted headroom makes it a poor fit for spiky or geo-skewed clients.
• Under partition the choice is explicit: PC (stall/reject to stay exact) vs PA (keep serving, reconcile later). State which you pick and why.

Pitfalls

• Independent per-region counters with no split and no sync — the 3× (N×) exploit.
• Strict global counter on the hot path for every request — cross-region RTT tanks p99.
• Per-region hard split assuming even distribution — geo-skewed clients get wrongly throttled.
• Affinity without failover — a region outage drops those clients' limiting entirely.

Takeaways

• Multi-region turns a rate limit into a consistency choice; name the PACELC stance.
• Strict global = exact + slow/less-available (PC/EC); local/soft = fast + approximate (PA/EL).
• Client→region affinity makes the shared quota local and exact — often the cleanest answer.
• Pick exactness only where a loose global cap actually costs money/abuse (billing); else favor availability.

---

Re-authored and deepened for this guide, applying CAP/PACELC (Abadi) to distributed rate limiting and standard multi-region quota patterns. Re-authored/Deepened for this guide.

I just read a lesson on **Multi-Region Rate Limiting** (System Design) and want to truly understand it. Explain Multi-Region Rate Limiting from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **Multi-Region Rate Limiting** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **Multi-Region Rate Limiting** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **Multi-Region Rate Limiting** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.