The gateway

The gateway is an intermediary placed in front of the services. It receives requests from consumers, applies the rules, passes them to the service concerned, and makes the return trip with the response.

It sits on the path of every call, and that defines both its value and its limits. The budget it has to hold can be put in figures: two to five milliseconds of its own time at the 50th percentile for an ordinary policy chain, around fifteen at the 99th. Those values are to be verified on your own estate before they are announced, and everything that follows on this page is explained by them.

Consumer

Application, partner, agent

Gateway

Authentication, quotas, routing

Services

APIs, streams, tools

What sets it apart from a reverse proxy and a load balancer

This is the most frequent confusion, and it has a practical consequence: plenty of organisations believe they have an API platform when what they have is a proxy with rules. All three components sit on the path of the call and do not manage the same unit.

A gateway does the work of a reverse proxy, TLS termination and routing included, and adds to it what requires knowing who is calling: the consumer identity, its quota, the contract it subscribed to, the life cycle of the version it uses.

The test that settles it is one question put to the operations team: can you say, without writing any code, how many calls partner X made last month and on which routes? A load balancer does not know. A reverse proxy knows by IP address, which does not separate two consumers behind the same egress. A gateway knows by subscription, and that is the only difference that changes anything.

Three families of traffic

The word gateway now covers three families, because there are three kinds of traffic to govern: synchronous calls, event streams, and tool invocations by agents. They share the same principles, authenticate, limit, observe, put under contract, and they differ by the contract and by the life cycle of the traffic.

APIs

Request-response, OpenAPI contract

Events

Continuous streams, AsyncAPI contract

Agents

MCP tools, burst invocation

APIs. The historical family. Request-response, an OpenAPI contract, policies applied per call. The protocols served go beyond REST, but the model stays the same: one call, one response, one identity, one quota.

Events. Exposing a Kafka or MQTT stream to external consumers raises the same questions as exposing an API: who subscribes, with what proof, at what rate, under what contract. Wiring them straight onto the message broker answers those badly. Internal addresses end up exposed, identities are managed in the broker, and nothing filters per consumer.

The gateway then applies API governance to these streams: client authentication, quotas, field filtering and masking per subscriber, protocol translation, an internal stream consumed over HTTP or pushed to the outside. The contract is written in AsyncAPI, the equivalent of OpenAPI for events: channels, operations, messages, schemas. A stream documented on the portal and subscribable like an API becomes a product on the same footing as the rest of the catalogue.

Agents and models. Agents consume APIs differently. They discover tools, described through the MCP protocol, and invoke them in bursts: a single task can produce dozens of calls. Two new needs follow from that.

Exposing what already exists, first. Products on the market generate MCP tool definitions from the OpenAPI contracts in the catalogue. Nothing has to be rewritten, the policies stay in place, and the agent goes through the same governance as any other consumer.

Governing that traffic, next. The agent's identity is distinct from that of the user it acts for. Quotas are counted in tokens consumed when what sits downstream is a model, which also calls for cost attribution per team and semantic caching. The design point that counts: discovering a tool does not carry the right to invoke it, and the decision is re-evaluated on every call.

Do you need three products?

Several platforms now carry the three families behind a single control plane, and that is the right evaluation criterion: one catalogue and one consumer identity, shared policies, three kinds of traffic. Three separate products mean three catalogues, three identity systems and three portals, and the promised unification will not happen on its own.

The pre-sales question that separates the field: does a consumer subscribing to an API, to an event stream and to an agent tool go through the same subscription object, or through three different screens?

What it does well

Routing. Mapping a public path onto an internal service that can change address, version or technology without the consumer knowing.

Access control. Checking the caller's identity and its right to call the route. The gateway validates the token, it does not decide business rights. The detailed split is in access.

Backend protection. Rate limiting, quotas, IP address filtering, maximum body size, timeouts, circuit breaker. The settings are in resilience. It is the function with the best return and the one least often switched on: it turns an outage into a degradation.

Traffic observability. Structured logging, correlation identifier, trace propagation. The gateway does not monitor, it produces the material that makes monitoring possible, detail in observability.

Light transformation. Rewriting a header, normalising a date format. Light is the word that counts, and the exact boundary is set in mediation.

What to refuse it

Business logic. A rule that starts with "if the client is of type B" has left the service. It is no longer tested or versioned with the code, and nobody reviews it when the business rule changes.

Orchestration. Calling three services, aggregating, handling partial failures is a service in its own right, not a policy. A gateway that orchestrates rebuilds an enterprise service bus, with the flaws that got enterprise service buses abandoned.

Application state. A cache is justified. Business state makes the gateway impossible to restart and blocks horizontal scaling.

Heavy transformation. Converting megabytes of XML into JSON on every call burns the most critical component in the chain on work that belongs to a facade.

The test that sums it up: if removing the gateway would break features, and not only security and control, too much lives inside it.

Two drifts to watch

The drift towards the bus. A header transformation, then a copied field, then an enrichment call. In two years the platform becomes the coupling point it was meant to remove. Reliable signal: a business change that requires a gateway deployment.

Manual configuration. Changes made in the console, with no history, no review, no way back. It is what turns up most often at the starting point of an incident during an audit, and the whole subject of industrialise.

The third classic drift, a single gateway for different trust regimes, is a topology choice. It is handled in internal and external.

Managed or self-hosted

The deciding criterion is rarely technical. It is regulatory, where the traffic is allowed to travel, or a matter of capacity, who will know how to run it. A self-hosted gateway with no on-call rota in place is a greater risk than a more expensive managed gateway.

Gateway and service mesh

Both route traffic and do not address the same axis. The gateway handles incoming traffic, between different trust domains. The mesh handles traffic between services inside one domain, with identity and encryption applied throughout. The full split is in gateway and service mesh.

The pillars it carries

The other two pillars do not go through it. Governance is declared in the control plane, discovery plays out on the portal.