> ## Documentation Index > Fetch the complete documentation index at: https://tyk.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # Cross-Region Rate Limits and Quotas with MDCB > How Tyk enforces rate limits and quotas when Data Planes run in more than one region, and which patterns give which accuracy guarantee. ## Overview With [Tyk MDCB](https://tyk.io/docs/api-management/mdcb.md), one Control Plane manages more than one [Data Plane](https://tyk.io/docs/api-management/mdcb.md#data-plane). The Gateways in a Data Plane share one Redis. Tyk stores rate limit and quota counters in that Redis, or in Gateway memory for the Distributed Rate Limiter. MDCB synchronizes configuration, not counters. It sends API definitions, policies, keys, certificates, and OAuth clients from the Control Plane to each Data Plane. It does not send request counts between Data Planes or back to the Control Plane. This design keeps every rate limit and quota check inside the Data Plane that receives the request. No request waits for a call to another Data Plane. A Data Plane also continues to enforce limits when it loses its connection to the Control Plane. The tradeoff is that each Data Plane enforces limits on its own traffic only. This behavior is the same if your Data Planes are in different geographical regions or in the same data center. This page describes what it means for accuracy, and the patterns you can use when you need a global limit. ## What MDCB Synchronizes | Item | Synchronized to Data Planes | Notes | | :- | :- | :- | | API definitions and policies | Yes | Includes the rate limit and quota values that a key or policy grants. | | Keys (sessions) | Yes | On demand at first use, or in advance with the [Synchroniser](https://tyk.io/docs/api-management/mdcb.md#mdcb-synchroniser). | | Quota resets | Yes | See [Quota Resets](#quota-resets). | | Rate limit counters | No | Local to each Data Plane. | | Quota counters | No | Local to each Data Plane. | ## Default Behavior Across Data Planes ### Quotas Each Data Plane keeps its own quota counter for a key in its local Redis. The counter has its own renewal time, which starts at the first request that the Data Plane receives in a quota period. A key with a quota of 1,000 requests per day can make 1,000 requests in each Data Plane. With two Data Planes, the key can make up to 2,000 requests per day in total. ### Rate Limits Every [rate limiting algorithm](https://tyk.io/docs/api-management/rate-limit.md#rate-limiting-algorithms) enforces the full limit inside one Data Plane. A key with a limit of 100 requests per second can make 100 requests per second in each Data Plane. With two Data Planes, the key can make up to 200 requests per second in total. This also applies to failover: when you move a client to another Data Plane, that Data Plane starts with a fresh limit for the client. Two algorithms have an additional effect across Data Planes: * **[Distributed Rate Limiter](https://tyk.io/docs/api-management/rate-limit.md#distributed-rate-limiter) (default):** It divides the limit between the Gateways of one Data Plane. Gateways find their peers through Redis publish and subscribe messages. These messages do not reach the Redis of another Data Plane. Thus, the limit is never divided between Gateways in different Data Planes. * **[Fixed Window Rate Limiter](https://tyk.io/docs/api-management/rate-limit.md#fixed-window-rate-limiter):** A client can use the full limit at the end of a window. It can use it again at the start of the next window. At a window boundary, a key can make up to 2x the limit in each Data Plane. Across two Data Planes, it can make up to 4x the limit. ### Quota Resets A quota reset is the one counter operation that reaches every Data Plane. When you reset a quota in Tyk Dashboard, MDCB sends a reset event to each Data Plane. Each Data Plane then deletes its local quota counter for that key. The Data Plane receives the event the next time it checks for key changes, as set by [slave\_options.key\_space\_sync\_interval](https://tyk.io/docs/tyk-oss-gateway/configuration.md#slave_options-key_space_sync_interval). > [!NOTE] > > An update to a key in Tyk Dashboard also resets the quota of that key in every Data Plane. To keep the current counters, add `suppress_reset=1` to the update request. Refer to the [Tyk Dashboard API](https://tyk.io/docs/tyk-dashboard-api.md) for the key endpoints. ## Patterns for a Global Limit If a consumer must not exceed one total limit across all Data Planes, select one of these patterns. Each pattern has a different accuracy guarantee. | Pattern | Accuracy guarantee | Latency | Failure isolation | | :- | :- | :- | :- | | [Per-Data Plane allocation](#per-data-plane-allocation) | Exact in each Data Plane. The global total never exceeds the sum of the allocations. | Local | Full | | [Consumer affinity](#consumer-affinity) | Exact, because all traffic for a key goes to one Data Plane | Local | Full, until failover | | [Replicated Redis](#replicated-redis) | Eventually consistent. Concurrent traffic in two Data Planes can exceed the limit before replication completes. | Local | Depends on the Redis product | | [One shared Redis](#one-shared-redis) | Exact | A round trip to the shared Redis on each request | None. Loss of the shared Redis stops every Data Plane. | ### Per-Data Plane Allocation Divide the global limit between the Data Planes, so that each Data Plane enforces only its share. Keys reach every Data Plane. Thus, you must attach each share to an API that only one Data Plane loads: 1. Use [API sharding](https://tyk.io/docs/api-management/api-sharding.md) to load a separate copy of the API in each Data Plane. 2. In the key or policy, give each copy its own [API-level quota](https://tyk.io/docs/api-management/access-control/sessions-and-keys/access-rights.md#api-level-limits-and-quotas). For example, 600,000 requests per month for one Data Plane and 400,000 for the other. * **Guarantee:** Each Data Plane enforces its share exactly. The consumer cannot exceed the global total. * **Tradeoff:** A Data Plane cannot use the unused share of another Data Plane. If traffic moves between Data Planes, you must change the allocation. ### Consumer Affinity Route all traffic for a consumer to one Data Plane, for example with DNS or with routing rules in front of Tyk. The other Data Planes serve that consumer only when you fail over. * **Guarantee:** The home Data Plane enforces the full limit exactly. * **Tradeoff:** After a failover, the new Data Plane starts with its own counter. The consumer can use more than the limit in the failover period. ### Replicated Redis Use a Redis product that replicates data between the Redis instances of your Data Planes, for example an active-active database. The counters in each Data Plane then converge over time. * **Guarantee:** Eventually consistent. Each Data Plane checks the limit against its local copy of the counter. The requests of the other Data Planes can arrive later. Thus, concurrent traffic in two Data Planes can exceed the limit. The size of the overshoot depends on replication lag and traffic rate. * **Tradeoff:** Replication lag is often longer than a short rate limit window. This pattern is more suitable for quotas than for per-second rate limits. ### One Shared Redis Connect all Data Planes to one Redis instance. * **Guarantee:** Exact, because all Gateways use the same counters. * **Tradeoff:** Each request makes Redis calls to the shared instance. If the Data Planes are far apart, for example in different geographical regions, this adds latency. If the shared Redis or the network link fails, some Gateways cannot reach it. These Gateways cannot validate keys or count requests. This pattern removes the main benefits of MDCB.