The single gateway is a false friend

The decision is usually taken without anyone taking it. You stand up a gateway for a first use case, often a partner flow, because that is the one with a budget, and since it is there, you push everything else through it.

Eighteen months later, the platform is in place, it works, and yet the internal teams call each other directly. Nobody decided that. It happened.

The mechanism

A single gateway has to serve different trust regimes with one configuration. Faced with that conflict, a reasonable organisation picks the strictest regime, the one belonging to the most exposed flow.

The consequence for an internal team that wants to expose an API:

• quotas calibrated for strangers, when the team is identified and reachable on Slack.
• a publication process designed for a partner contract, with review and notice.
• an extra network round trip, sometimes through the exposure zone, to reach a service running three metres away.
• added latency it cannot justify to anyone.

That team has a project to deliver. It does what anyone does: it calls the service directly.

And there the platform loses the one thing that justified its existence, visibility. The day you want to know who consumes what so you can deprecate an API, the answer is incomplete, and nobody knows by how much.

Why this is rarely fixed

Because nothing breaks. There is no incident, no alert, no ticket. There is simply a platform whose real perimeter shrinks slowly while its architecture diagram stays accurate.

The symptom shows in a number nobody computes: the share of service-to-service traffic that actually crosses the gateway. If it falls from one quarter to the next, the platform is being bypassed.

It can be computed without a project. The numerator is in the gateway logs. The denominator is in network telemetry: the pod-to-pod flows of a mesh such as Istio or Cilium, or failing that the virtual network flow logs at your cloud provider. Both numbers already exist. They are simply never placed side by side, because they belong to two different teams.

The real reasons to keep a single gateway

There are some, and they are legitimate.

Getting started. At launch, with five APIs and a single regime genuinely at stake, one gateway is the right call. Two platforms to operate for five APIs is over-engineering that will cost more than the problem it prevents.

No team. Two gateways mean twice the operations, and one on-call rota that has to know both. Without the people, the second gateway is a risk, not a protection.

Licence cost. Some models bill per control plane or per deployed data plane, and the surcharge is public: at Kong, a second hybrid gateway adds two hundred dollars a month, a dedicated gateway five hundred. Separation can therefore be priced before it is decided, and the amount is almost always lower than the committee imagines.

These three reasons have one thing in common: they are temporary. The problem is not starting with a single gateway. The problem is never deciding to leave it.

What costs a lot, and what costs nothing

The good news: topology is not the irreversible decision. Two details are, and they cost nothing on day 1.

Domain names. If internal traffic and external traffic share the same host name, separating them one day forces a migration on every consumer. A single api.example.com today means, tomorrow, a code change at every caller, a test cycle at each of them, a rollback to prepare for each of them.

Two distinct names from the start, api.example.com and internal-api.example.com, even served by the same gateway, make the later separation invisible to everyone: it becomes a DNS record change. One line of configuration today, several months of coordination in two years.

The authentication boundary. Decide early exactly where the token is validated and what is passed on behind it. Moving that boundary later touches every service, one by one.

The rest, instance counts, products, network zones, changes with money and time. Those two change with the cooperation of all your consumers, which is another currency.

The question to ask in committee

One question, and it cuts through better than an architecture document:

What happens if the external gateway goes down?

If the answer is "the internal teams can no longer work", the topology is wrong, whatever the product, whatever its ranking, whatever the quality of its configuration.

The detail of the possible topologies, single, separate, hybrid, or gateway plus service mesh, is covered in internal flows, external flows and hybrid gateway.