There are 3 main avantages:
1. Better uptime during crisis:
Imagine a scenario where your master DC burns down, so no MongoDB, no Redis, no MDCB component, and no master Dashboard or Gateway. At the same time, you are experiencing increasing load in your other DC’s.
With the dashboard-only setup (where you have a master gateway and dashboard with the increased round trip time)
- Gateways in other DCs would not be able to scale, since the gateways cannot bootstrap from the master dashboard
- Gateways in other DCs will no longer be able to validate most requests because Redis has failed
- Traffic would grind to a halt until the DB and Redis can be brought back on-line
With MDCB-enabled gateways:
- Gateways “stash” an encrypted version of their API and Policy configuration in the local redis
- Gateways that are coming online during a scaling event can detect master MDCB downtime and will use the “last good” configuration found in redis
- Since running gateways have already been caching tokens that are in the active traffic flow from MDCB up until the downtime event, all gateways can service existing traffic, only new tokens will be rejected (and this can be mitigated by injecting those directly into the gateways using the local slaved gateway API)
- Once master is restored, the gateways will all hot-reload to fetch new configurations and resume normal operations
- Gateways will only record a buffered window of analytics so as not to overwhelm redis or flood MDCB when it comes back online
Overall, the MDCB based setup is more resilient. It also means that redis and mongo in master can be configured for DR (hot backup or replica to another DC), and use DNS switching to swap over to a hot standby.
Admittedly the above DR can be handled with the dashboard-only setup, but it does involve additional licensing and you still have the problem of immediate downtime.
2. Latency reduction
Because the gateways cache keys and all operations locally, all operations can be geographically localised - this means that traffic from Canada, to Canada will all have rate limiting and checks applied within the same DC and round trip time is massively reduced.
Also, the lookup to MDCB is via a resilient compressed RPC channel that is designed to handle ongoing and unreliable connectivity, it is also encrypted, and so safer to use over the open internet or inter-DC links.
This can be done with Redis using new TLS features, but (as far as I am aware) the gateways do not support this yet.
3. Organisational Benefits
MDCB-slaved gateways are tied to a single organisation in the dashboard - this means that you can set up different teams as organisations in the dashboard, and each team can run it’s own set of gateways that are logically isolated.
This can be achieved with a dashboard-only setup, but requires gateway sharding (tagging) and behavioural policy on the user’s side to ensure that all APIs are tagged correctly, otherwise they do not load.
With an MDCB setup you get the ability to do both - segment out teams with their own gateway clusters, and also sub-segment those gateways with tagging.
Additional cost: Yes MDCB has a separate price point
Delayed checks for key, rate checking, since these are “cached” locally: This only happens on the first request that any single gateway in a DC cluster sees, this has one round-trip to the master DC to fetch and cache the data locally, however after this all operations happen locally, so the setup behaves the same way as a fully-dc-local gateway deployment would work (see above). If using “generative” tokens, such as JWT or the OIDC protocol, then there is no round-trip at all.
This is only partially correct, the gateways ill register with the dashboard in Canada north, but will also need to connect with the redis DB there, which may be undesirable as usually it is recommended to lock redis down into it’s own VPC and only allow trusted firewalled traffic.
Hope that helps