Architecture pattern
Hybrid API gateway
Manage every gateway from one cloud control plane while the data planes that carry traffic run next to your services, in the cloud or on premises.
- Caller
- Gateway
- Component you run
- Control, identity or policy
- Request
- Configuration or credentials
How it flows
- Partner apps to Data plane (Your cloud region)Partner traffic enters at the nearest data plane.
- Internal apps to Data plane (Your data centre)Internal traffic stays inside the corporate network.
- Data plane (Your cloud region) to Cloud services; Data plane (Your data centre) to Core systemsEach data plane proxies to services next to it.
- Data plane (Your cloud region) and Data plane (Your data centre) to Control plane (control)Data planes connect out to the control plane over mTLS, pull configuration and send telemetry. No inbound ports are opened.
The problem
Large organisations rarely run everything in one place. Some services live in a public cloud, some in a data centre, some in a regulated region. Running a separate gateway estate in each location means separate configuration, separate tooling and inconsistent policy.
Routing all traffic through one central gateway fixes consistency but adds latency, creates a single choke point, and can move data across boundaries it should not cross.
When to use it
- Services span several clouds, regions or data centres.
- Data residency or network rules require traffic to stay local.
- You want one place for configuration, policy, analytics and a developer portal.
- You prefer not to operate the management layer yourself.
When not to
- Everything runs in one cloud region and a single managed gateway already covers it.
- Policy forbids any outbound connection from the environment, even for configuration. A fully self-managed control plane may be required instead.
- The team cannot operate gateway nodes. Data planes are still your infrastructure to run, scale and patch.
Key components
- Control plane. Holds configuration, policy, certificates and analytics. It never sits in the request path.
- Data planes. Gateway nodes deployed close to services. They keep serving traffic with their last known configuration if the control plane is unreachable.
- Outbound, mutually authenticated connection. Data planes connect to the control plane, so no inbound firewall rules are needed in your environments.
- Telemetry pipeline. Metrics and logs flow back to the control plane, with options to keep sensitive payloads local.
Kong Konnect uses this split between a managed control plane and self-hosted data planes. Most enterprise gateways offer a similar hybrid mode.
Trade-offs
- Configuration lag. Changes propagate to data planes asynchronously. Usually seconds, but plan for it during incidents.
- Split responsibility. The vendor runs the control plane; you run the data planes. Be clear on who owns upgrades, version compatibility and incident response.
- Telemetry and residency. Decide what metadata may leave each environment, and configure the data planes accordingly.
- Offline behaviour. Data planes keep working without the control plane, but you cannot change configuration until it returns.
Explore further
Lab: One request, eight plugins.→Follow a single AI request through an ordered chain of gateway plugins, switch any of them off and see what changes.
Lab: Same prompt. Three clocks.→Send one curated prompt to several LLM providers at once and compare time to first token, total time, tokens per second and cost.
Read: API Gateways for AI Workloads→How API gateways are evolving to handle the unique demands of LLM traffic — streaming, token limits, and semantic caching.