Multi-gateway rate limiting with a single control plane

A fintech or SaaS company runs APIs through more than one gateway — maybe Amazon API Gateway for some services, an internal Kong instance for others, and a legacy Apigee edge deployment that hasn't been migrated yet. They want to enforce a rate limit of 1000 calls per minute for a specific partner across all of those, but each gateway tracks its own counters independently. The partner can hit 1000 on each gateway simultaneously and blow through three times the intended limit. Complaints surface this as 'latent connections with 3rd party API' and the desire for 'better rate limiting functionality' alongside API discovery.

The reason this hasn't been solved cleanly is that each gateway vendor has every incentive to be the single gateway — their rate limiting works perfectly inside their own system, and they'd prefer you consolidate on them rather than federate. A neutral layer that spans multiple gateways is structurally inconvenient for every incumbent to build, because building it well would implicitly validate using a competitor alongside them.

What's missing is a thin coordination layer that sits in front of or alongside multiple gateways, holds shared rate limit counters per API key or partner identity in a fast distributed store, and pushes allow/deny decisions back to each gateway without requiring any gateway migration. The 'same region' constraint users mention — 'everything should be in the same region; it cannot integrate with other region resources' — is a direct symptom of this: each gateway's rate limiter is local, and global enforcement doesn't exist.

The business case is that a single rate limit overage incident with a partner can cause SLA violations, unexpected infrastructure bills, and in regulated industries, a compliance event. Companies paying for API management are paying specifically to not have these incidents. A tool that charges $X per month to prevent a $50K overage event or SLA penalty is an easy buy.

What to build

Build a rate limit coordination service that exposes a single gRPC or HTTP endpoint, maintains shared counters per API key across Amazon API Gateway, Kong, and Apigee using Redis with a multi-region replication option, and integrates via each gateway's external authorization hook — deployable as a single Docker container or as a managed service.

Where to start

Target companies in the middle of a gateway migration — specifically those moving from Apigee Edge to Apigee X or from Apigee to Kong — because during migration they're running two gateways simultaneously and rate limit coordination is an acute, time-boxed, high-stakes problem they're actively trying to solve right now.

The hard part

Latency is the kill shot — if the coordination check adds more than 2-3ms to every API request, engineers will reject it regardless of the rate limiting benefit, so the architecture has to be local-cache-first with async counter reconciliation, which means the consistency guarantees are probabilistic rather than strict, and you have to explain that trade-off to security-conscious buyers without losing them.

How it makes money

Usage-based pricing per million API requests that pass through the coordination layer, with a minimum monthly floor — scales naturally with the customer's traffic and aligns cost with the value delivered.