Internal and external
Three exposure regimes, four gateway topologies and what they mean in operations, with the two expensive decisions to take from the start.
Not all APIs in an organisation share the same level of trust or the same rate of change. Deciding how many gateways serve which flows is the architecture decision that shapes a platform most, and the most expensive to change: its effects are visible to consumers.
Three regimes
| Internal | Partner | Public | |
|---|---|---|---|
| Consumer | Teams inside the organisation | Companies under contract | Unknown, open sign-up |
| Authentication | Service token, mTLS | OAuth2 client credentials, mTLS | OAuth2, API keys |
| Rate limits | Generous, guards against mistakes | Contractual | Strict, defensive |
| Change | Fast, negotiable | With contractual notice | Slow, versioned |
| Dominant concern | Decoupling | Service commitment | Abuse and cost |
Serving all three with a single configuration forces you to choose the most restrictive one. Internal teams inherit quotas designed for strangers, they route around the platform, and visibility leaves with them.
Four topologies
Single gateway. Simple to operate, but the strictest regime applies to everyone, internal traffic crosses the exposure zone, a public spike degrades the internal side. Defensible at the start.
Two separate gateways. One internal, one external, often two products. Failures and rules are isolated, but there are two platforms to operate and a risk of drift between two definitions of the same API. The most common one as soon as a partner flow exists.
One control plane, several data planes. APIs and policies are defined once, gateways are deployed per zone.
Control plane
APIs, policies, contracts, once only
Data planes
Internal gateway
Private network
Partner gateway
DMZ
Cloud gateway
As close as possible to the services
Each zone keeps rules that fit it without duplicating the definitions. The model demands the ability to operate several deployments, and a reading of the licence agreement: several vendors charge per data plane. This is the topology mature platforms converge on.
External gateway and internal service mesh. Exposure goes through the gateway, calls between services through a mesh. The exact split of roles is covered in gateway and service mesh.
Two decisions not to postpone
Domain names. If internal and external traffic share a name, separating them later forces a migration on every consumer. Distinct domains from the start, even served by a single gateway, make the switch invisible.
The authentication boundary. Settle early where the token is validated and what is passed on behind it, see access. Moving that boundary touches every service at once.
The gateway as a switching point
The indirection point also serves migrations: replacing an existing system route by route, moving the routing rule as releases go out, with no single switchover date. The rule is set per route, per consumer or by percentage, and rolling back takes one operation. The trap in these migrations is organisational, the hard routes stay behind and the organisation ends up operating two systems: a retirement date for the old one, set at launch and held to, is the only guardrail that works.
The test that judges a topology fits in one question: if the external gateway goes down, can the internal teams still work? If the answer is no, the split is wrong, whatever the product.
Updated August 2026.