Skip to main content

​
Overview

With Tyk MDCB, one Control Plane manages more than one 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

​
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 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 (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: 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.
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 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.

​
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 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. 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.