The control plane
The control plane declares what the gateway enforces: APIs, policies, identities. What it holds, the test that exposes a badly designed product, and multi-gateway.
The control plane is where intent gets declared: which APIs exist, which policies apply, who is allowed to call what. No traffic passes through it. The gateway enforces, the control plane decides.
Control plane
APIs, policies, identities, history
Gateways
Serve traffic with the last configuration received
The separation, and the test that verifies it
A call crosses the gateway in a few milliseconds. A policy change takes as long as a review. These two regimes must never depend on each other, and the rule that follows can be tested: the gateway must keep serving with its last known configuration while the control plane is down.
The test is run on a trial platform, by shutting the control plane down for a day. Three things usually degrade, and you need to know which ones you accept: new subscriptions and key rotations stop propagating, exact quota counters depend on a central store that can fall over with the rest, and above all a gateway instance restarted during the outage may never come up, having no way to fetch its configuration.
That last point corrects the test itself: shutting the control plane down is not enough, a gateway has to be restarted during the outage. Without that the test always passes, and on the day of a real incident you find that a control plane failure blocks scaling out. The question deserves to be asked before you buy, the answer deserves to be verified.
What it holds
- The API registry: contracts, versions, lifecycle states.
- The policies, with their scope: global, per API, per consumer.
- Application identities: declared applications, keys, subscriptions. End-user identities stay with the identity provider.
- The environments, with a traced promotion from one to the next: the same API does not have the same policy in staging and in production.
- The history: who changed what, when, and how to roll back.
Its interface is judged on its API
The console is there to explore and to diagnose. It must not be the way production gets modified, for the reasons set out in industrialise. Three questions assess a product:
- does the configuration export in full into version-controlled files.
- does it import back into an empty environment and reproduce the same state.
- is a change made outside that path detected and reported?
A product that fails the third one condemns you to a permanent gap between the declared and the real, with no way to measure it.
Multi-gateway
Few organisations have only one gateway: a legacy one, one per cloud provider, one that arrived with an acquisition. Two strategies exist. The hybrid topology, a single control plane that manages its own data planes deployed by zone, described in internal and external. And federation, a governance layer that inventories and monitors gateways from different vendors without replacing them. Several products on the market now position themselves there.
In both cases the first question is the same: which gateways are managed, which are not. The honest inventory fits on one page, and the incidents happen in the unmanaged column.
The pillars it carries
| Pillar | What the control plane holds of it |
|---|---|
| Governance | This is where the lifecycle gets declared: versions, deprecations, contracts, who is allowed to publish what |
| Observability | No traffic passes through it, but it is the one that knows what exists. Without its inventory, the gateway's measurements attach to nothing |
The other three pillars do not go through it. Access and mediation apply on the call path, so at the gateway. Discovery plays out on the portal.
Updated August 2026.