The Real Jobs of an API Gateway

In my last piece

I argued that API gateways — and their new event-driven cousins — are not integration styles. They are not lifeguards of your API initiative either, even if they are often presented that way. That post was about breaking a myth. But myths leave a vacuum. If gateways are not styles and not strategies, then what are they really good for?

That is the question this post tries to answer.

Because here’s the truth: gateways are not the villains. They are useful, even indispensable, when positioned correctly. The trouble begins when they are loaded with responsibilities they can never fulfil. A gateway is brilliant at enforcing and exposing, but it cannot design, govern, or align APIs with business value. Put differently: gateways are helpers, not architects.

So let’s get practical and look at what jobs an API gateway can do well, where it adds no value, and how it should be framed inside a modern platform operating model.

Photo by Lala Azizli on Unsplash

The Real Jobs: What Gateways Do Well

The original API Gateway pattern, described by Chris Richardson in the context of microservices, was never about strategy. It was about creating a single entry point that could handle cross-cutting concerns. That idea holds up well today.

The real value of gateways is in taking the undifferentiated heavy lifting off the plates of product teams. Here are the jobs they excel at:

Standing guard.
A gateway enforces authentication and authorisation, validates tokens, applies rate limits and quotas. These are jobs that must be consistent everywhere. You do not want every team to roll their own approach to access control.

Routing and managing traffic.
Gateways direct requests to the right backend, balance loads, handle failover, and sometimes even bridge protocols. Expose REST to the outside, talk gRPC internally, and keep it all invisible to the consumer. This is plumbing work, but without it, the consumer experience falls apart.

Applying cross-cutting policies.
Every enterprise has rules that apply everywhere: encrypt traffic, log requests, mask headers, check compliance. The gateway is the natural choke point to apply these policies once and uniformly.

Providing observability.
From their vantage point at the edge, gateways can collect metrics and traces: throughput, latency, error rates, anomaly detection. They help platform teams see how traffic flows, without instrumenting every individual service.

Supporting the developer journey.
Many gateways provide niceties like sandboxing, mocking, or auto-generated documentation. These are not a substitute for thoughtful API design, but they make the first contact for consumers smoother.

Put together, these jobs show the true purpose of a gateway: it handles the repetitive operational concerns so that development teams can focus on solving real business problems.

The Wrong Jobs: What Gateways Can Never Do

The trouble starts when we forget that gateways are facades. They make what already exists more consistent and controllable. They do not create or define it. Expecting more leads to failure.

A gateway cannot design an API or event model. It cannot decide whether a use case needs a resource-based interface, a query endpoint, or an event stream. That requires understanding consumers and domain logic.

A gateway cannot define ownership or lifecycle. It cannot tell you who is responsible for a breaking change, how a deprecation should be communicated, or whether an API is still delivering value.

A gateway cannot replace governance. Enforcing TLS or logging traffic is not the same as deciding which APIs should exist, or how they align with strategy. Governance is about direction and ownership; gateways only enforce rules at runtime.

And above all, a gateway cannot set the strategy. It cannot decide if the organisation should be event-driven, whether to invest in certain domains, or how APIs deliver value. A tool cannot substitute for leadership.

Put bluntly: gateways enforce what exists. They do not decide what should exist.

Gateways in the Platform: Helpers, Not Centres

If we stop asking gateways to do jobs they are not suited for, what is left? The most effective way to think of them is as services of the platform team.

In a Team Topologies perspective, stream-aligned teams own APIs and events. They decide what to build and how to evolve it, because they are closest to the business. What they should not be burdened with is reinventing cross-cutting concerns like authentication or routing logic.

The platform team provides gateways as part of a paved road: ready-to-use templates, policy-as-code modules, observability hooks, and easy onboarding flows. Instead of every team figuring out how to configure the gateway from scratch, they plug into golden paths that give them consistent security and monitoring for free.

Enabling teams play a supporting role, helping with design and lifecycle — the jobs gateways cannot do. Complicated-subsystem teams may own substrates like brokers or meshes. Together, this creates an ecosystem where gateways are guardrails, not bottlenecks.

Seen this way, the gateway becomes what it should always have been: a helper that reduces cognitive load, enforces consistency, and gives visibility at scale. Not the star of the show, not the strategy, but an enabler that keeps the platform safe and predictable.

A Simple Litmus Test

If you are unsure whether you are expecting too much from your gateway, ask yourself a simple question:

👉 Am I trying to enforce something that already exists, or am I trying to architect through infrastructure?

If it is the first, the gateway is the right tool. If it is the second, you are loading the wrong job on the wrong shoulders.

Closing Thoughts

Gateways are not integration styles, and they are not lifeguards. But they are not irrelevant either. They are essential helpers that take care of access control, routing, policies, observability, and developer onboarding. They allow product teams to focus on delivering value, while the platform provides consistency and safety.

Use them for the jobs they do well, and stop asking them to carry strategic weight they were never meant to bear. Helpers can make you faster and safer. Lifeguards they are not.

In the next post, I’ll explore how this applies to event gateways — and why routing events does not magically make an organisation event-driven.