What Is an API Gateway? 7 Things Every Developer Should Know (With Examples)

October 28, 2026 · Web Development

A monolith has one address, so clients have an easy life. Break it into services and that simplicity breaks: the mobile app must now know the addresses of the user, orders, and payments services, plus a different auth scheme and error format for each. What is an API gateway exactly? It is the component that puts that simplicity back — a single entry point between clients and backend services. Every request hits the gateway first, the gateway decides which service should handle it, and the client only ever learns one hostname, one auth scheme, and one error format. This guide explains the jobs a gateway actually does, the patterns it enables, and the point at which it stops helping.

1. Without a gateway, clients carry the whole map

Picture a shop app split into three services. Without a gateway, the mobile app ships with three hostnames baked in, three sets of retry logic, and three auth behaviours to keep in step. Add a notifications service and every client needs an update before it can use it; move a service to a new host and the same clients need touching again. Your backend topology has leaked into every client you will ever ship, and every change to it becomes a client release.

With a gateway, the client knows one thing: the gateway's address. New services appear behind it without any client changing. A service moves, scales, or splits in two, and the gateway's routing table is the only thing that changes. That decoupling is the gateway's real value — everything else it does is a policy you could, in principle, put somewhere else, but the single entry point is the one thing only a gateway gives you.

2. The six jobs a gateway does

Routing is the first job and the one everything else hangs off: match the incoming request — usually by path, sometimes by header or hostname — and forward it to the right service. A request to /users/42 goes to the user service; /orders goes to the orders service. Our REST API guide explains the resource-and-endpoint model those paths express.

Authentication is the second. The gateway checks the caller's credential once, at the edge, and either rejects the request there or forwards it with the caller's identity attached, so services do not each re-implement token checking. This is where API keys and bearer tokens usually get validated — but validation is not authorization, a distinction section 6 returns to.

Rate limiting is the third, and it is most useful at the gateway because the gateway sees all traffic for all services in one place. A per-client or per-API limit enforced here protects every service at once, instead of each service defending itself separately. Our rate limiting guide covers the algorithms — fixed window, token bucket — that gateways typically implement, and the 429 responses clients should expect.

Transformation is the fourth: translating between what the client speaks and what the service speaks — rewriting a path, adding or stripping a header, or presenting one API version while the service behind it runs another. Used sparingly, it lets an old client keep working while the service evolves underneath it.

Aggregation is the fifth. A mobile screen needing a user profile, recent orders, and a delivery estimate would otherwise make three round trips; the gateway can fan out to the three services, combine their answers, and return one response — at the cost of owning a piece of orchestration logic.

Observability is the sixth and quietest job. Because every request passes through the gateway, its logs and metrics give a complete picture of API traffic: which endpoints are hot, which clients misbehave, and where errors cluster.

3. Routing in code: a table, not magic

Strip away the marketing and routing is a lookup table: match the request path against the routes, longest match first, and forward to the winning service. The real gateway adds health checks, retries, and timeouts around the same idea:

routes = {
    "/users": "user-service",
    "/orders": "order-service",
    "/payments": "payment-service",
}

def route(path):
    for prefix in sorted(routes, key=len, reverse=True):
        if path == prefix or path.startswith(prefix + "/"):
            return routes[prefix]
    return None

route("/users/42")        # -> user-service
route("/orders/7/items")  # -> order-service
route("/payments")        # -> payment-service
route("/unknown")         # -> None (gateway answers 404 itself)

Two details are worth carrying into real configuration. First, longest-prefix matching matters: a route for /orders must not swallow /orders-admin, hence the exact-match-or-slash-boundary check. Second, the gateway itself answers unknown paths — a gateway 404 means "no such route", a different failure from a service's own 404. Logging that distinction speeds up routing debugging.

From the client's side, nothing changes about how a request looks. A call through a gateway is an ordinary HTTP request with an authorization header, exactly as it would be to a service directly:

curl https://api.example.com/users/42 \
  -H "Authorization: Bearer <your-token>"

The gateway validates that token, routes to the user service, and returns its response. The client cannot tell — and should not need to tell — whether one service or thirty answered behind that address.

4. Three patterns gateways enable

The first pattern is one gateway for everyone. It is the simplest setup and the right default for most teams: a single entry point, a single routing table, and one set of policies. Its weakness is that one gateway must serve clients with very different needs, so its responses tend to converge on a lowest common denominator.

The second pattern is backends for frontends, or BFF: each client type gets its own gateway, aggregating and shaping responses for that client — a compact payload for mobile, a fuller one for web. The cost is real: several gateways to run, and shared logic that must stay in step. Reach for BFF when client needs genuinely diverge, not as a starting point.

The third pattern is the strangler approach to migration. Point the gateway at the old monolith first, then move one route at a time to a new service behind the same gateway address. Clients never notice, because their address never changes; without a gateway, every client cutover must be coordinated.

5. Gateway vs load balancer vs reverse proxy vs CDN

These four components overlap, so the distinctions are worth stating plainly. A load balancer spreads traffic across copies of the same service; a gateway routes across different services and adds API policies on top. A reverse proxy forwards requests on behalf of backend servers and can cache and terminate TLS; a gateway is a reverse proxy specialised for API traffic. A CDN caches content at the edge so requests never reach your servers; a gateway handles the requests that do arrive. Typically they appear in this order: CDN, gateway, load balancer, services.

	Routes across	Main extra job
Load balancer	Copies of one service	Health checks, failover
Reverse proxy	Any backend servers	Caching, TLS termination
API gateway	Different services	Auth, rate limits, aggregation
CDN	Edge caches, not services	Serving cached content close to users

6. What stays with the service, not the gateway

A gateway that does everything becomes a new monolith with a worse name. The honest boundary, stated clearly in the APISIX terminology documentation, is that gateway policies do not replace service-level authorization, data validation, workflow state, or business logic. The gateway can check that a token is valid; it should not decide whether this user may cancel that order, because that decision needs the order's state, which only the orders service has. Every business rule in the gateway is a rule maintained in two places.

The same restraint applies to rate limiting honesty: a gateway rate limit reduces abusive traffic, but it does not by itself provide complete denial-of-service protection, and request filtering at the gateway does not make an upstream safe from every injection or application vulnerability. Teams that treat the gateway as a security boundary, rather than one layer of several, learn this the expensive way.

7. When not to use one

A gateway is an extra hop, a new component to operate, and a single point of failure unless you run it redundantly — three costs that need a reason. A single-service application does not have that reason, and a small team with two services and one client may not either; a simple reverse proxy with auth middleware can carry them a long way. Even at scale, a gateway that accumulates business logic and per-service authorization rules becomes the hardest component to change — the bottleneck it was built to remove, relocated.

The test is simple: if removing the gateway would force every client to learn your service map, you need one. If it would change nothing except one fewer hop, you do not — yet. Add it when the map starts leaking into clients, and keep its policies lean.

Common mistakes to avoid

• Putting business logic in the gateway. Authorization rules and workflows belong in the service that owns the data.
• One gateway per service. That recreates the client-side map problem the gateway exists to solve.
• Treating gateway auth as full security. Token validation at the edge does not replace service-level authorization or input validation.
• Ignoring the single point of failure. Run gateways redundantly, or use a managed one — a single instance takes everything down with it.
• Letting transformation sprawl. Every bespoke rewrite is a compatibility promise you now maintain forever.
• Adding a gateway to a single service. An extra hop with no map to hide is pure cost.

Done well, an API gateway is almost invisible: clients call one address, services evolve behind it, and nobody thinks about the component in the middle — until it is missing, and every client suddenly needs to know the whole map again. It sits alongside the load balancer, the rate limits that protect the edge, and the REST APIs it routes between. Reference: Apache APISIX's API gateway terminology and TechTarget's API gateway definition.

Frequently asked questions

What is an API gateway in simple terms?

An API gateway is a single entry point that sits in front of a group of backend services. Clients send every request to the gateway, and the gateway routes each request to the service that should handle it, applies shared policies such as authentication and rate limiting, and returns the response. The client never needs to know how many services exist behind it.

Is an API gateway the same as a load balancer?

No, although a gateway usually balances load as part of its job. A load balancer spreads traffic across copies of the same service. A gateway routes traffic across different services, and adds API-specific work on top: authentication, request transformation, aggregation, and per-API rate limits. Think of load balancing as one feature inside a gateway, not the whole product.

Is an API gateway the same as a reverse proxy?

A gateway is a specialised kind of reverse proxy: it forwards requests on behalf of backend services, like any reverse proxy does, but it is built for API traffic. A plain reverse proxy can forward and cache; a gateway adds routing by API path, per-route policies, and aggregation of several services into one response.

Do I need an API gateway for a single service?

Usually not. With one service, the gateway is mostly an extra hop: you can add authentication and rate limiting inside the service itself. A gateway earns its keep when there are several services, several client types, or external partners — that is when a single entry point, one auth scheme, and one error format start saving real work.

Does an API gateway slow down requests?

It adds one hop, so a badly configured gateway can add latency — every policy it runs costs time. A well-run gateway keeps that cost small, and can even save round trips by aggregating several backend calls into one response. Keep gateway policies lean, measure the added latency, and never put business logic in the gateway that belongs in a service.

What is the difference between an API gateway and a service mesh?

A gateway handles traffic coming into the system from clients, at the edge. A service mesh handles traffic between services inside the system, service to service. They complement each other: the gateway is the front door, and the mesh manages the corridors behind it. Many teams run a gateway without a mesh, and add a mesh only when service-to-service traffic itself needs managing.

Should the gateway check authorization, or just authentication?

The gateway is a good place to check authentication — is this caller who they claim to be, and is their token valid? Authorization — is this user allowed to read this particular order — belongs in the service that owns the data, because only that service knows the rules. A gateway that tries to enforce every business rule becomes a second, shadow copy of your application logic, and the two copies will drift apart.

What happens if the API gateway goes down?

Everything behind it becomes unreachable from outside, which is why production gateways run in redundant pairs or as a managed service with its own redundancy. Treat the gateway as critical infrastructure: monitor it, deploy it with the same care as your most important service, and never assume a single instance is enough.

Related articles