API gateway: a team contract, not just a routing tool
Most API gateway conversations stay at the infrastructure level. The part that actually matters is what it forces teams to agree on before they write a line of code.
When teams start adding an API gateway, the conversation usually covers routing, rate limiting, and authentication. Those are real concerns. But in my experience the more lasting impact is not technical - it is organisational.
An API gateway forces the question of who owns the contract between systems. That question has a way of surfacing disagreements that were silently building for months.
What the gateway actually centralises
At its most basic, the gateway sits between callers and the services they reach. It handles things that would otherwise be repeated in every service: auth token validation, logging, throttling, SSL termination. Consolidating those is genuinely useful.
But the more important thing it centralises is the definition of the public interface. Once you have a gateway in front of your services, you have a natural place to declare "here is what the outside world sees." Everything behind that boundary is an implementation detail.
The contract question
The moment a team has to declare a public contract at the gateway, hard decisions appear:
- Which fields are stable and which can change without notice?
- Who reviews a change that would break a downstream caller?
- How are breaking and non-breaking changes classified?
- What is the versioning policy?
None of these are tool questions. They are team-discipline questions. The gateway just makes the absence of answers visible.
Where this goes wrong
The common failure mode I see is a gateway introduced as a performance or security measure, with no ownership model attached. Six months later there are 40 endpoints registered, nobody knows who owns which one, and a breaking change to a service owned by Team A silently breaks a consumer owned by Team B.
This is not a gateway problem. It is a process problem made visible by the gateway.
A lightweight governance model
You do not need a full change-management process. What I usually recommend to start:
- Each service has a named owner who approves gateway-level changes.
- Any change that modifies a response shape requires a version bump or advance notice.
- A shared changelog for the gateway - even a simple markdown file - shows what changed and when.
- Callers must be listed explicitly, at least for internal services.
These habits cost almost nothing when introduced early. They are expensive to retrofit after the fact.
Practical starting point
Before adding a gateway, write down two things: who owns each downstream service, and what the expected stability guarantees are for each interface. If you cannot answer those questions, the gateway will not create clarity - it will just route the confusion more efficiently.