API Gateway in Microservices: Role, Patterns, Tradeoffs

An API gateway in microservices architecture is the single entry point that sits between clients and your backend services. Instead of a mobile app or frontend calling ten different services directly, it calls the gateway, which routes the request, handles cross-cutting concerns like auth and rate limiting, and returns a response. This solves the core problem of microservices: you've split one application into many independently deployable pieces, but clients still need something that looks and behaves like a single, coherent API.

Without a gateway, every client has to know the network location of every service, implement its own retry logic, handle authentication against each service separately, and deal with the fact that services get renamed, merged, or scaled independently. The gateway absorbs all of that complexity in one place so the rest of your system doesn't have to.

What an API Gateway Actually Does

In a typical microservices setup, the gateway handles a fixed set of responsibilities so individual services don't have to duplicate them:

• Routing — mapping incoming paths like /orders/ or /users/ to the correct backend service, including versioned routes
• Authentication and authorization — validating API keys, JWTs, or OAuth tokens before a request ever reaches a service
• Rate limiting and quotas — protecting backend services from being overwhelmed by a single noisy client
• Request/response transformation — reshaping payloads, stripping internal fields, aggregating responses from multiple services into one
• Observability — centralized logging, metrics, and tracing for every request that enters the system
• TLS termination — handling HTTPS at the edge so internal services can communicate over plain HTTP inside a trusted network

None of these are things a single microservice should be responsible for on its own. If every service implements its own auth check, rate limiter, and logging format, you end up with inconsistent behavior and a maintenance nightmare when policies change.

Gateway Patterns Worth Knowing

There isn't one correct way to deploy a gateway. The pattern you pick depends on how many client types you serve and how much you want to centralize.

Single gateway. One gateway in front of all services, all clients go through it. Simple to operate, but it can become a bottleneck and a single point of failure if not scaled properly.

Backend for Frontend (BFF). Separate gateways per client type — one tuned for the mobile app, one for the web dashboard, one for third-party integrations. Each BFF shapes responses specifically for its consumer instead of forcing every client to parse a generic payload.

Gateway with service mesh. The gateway handles north-south traffic (external clients into the cluster), while a service mesh like Istio or Linkerd handles east-west traffic (service-to-service calls inside the cluster). This split keeps the gateway simple and pushes internal concerns like retries and circuit breaking into the mesh.

For most teams starting out, a single gateway is the right call. BFFs and meshes solve problems you'll have at scale, not problems you have on day one.

Build vs Buy

Teams generally reach for one of three options:

1. Self-hosted gateways — Kong, Tyk, KrakenD, or a hand-rolled Node/Go proxy. Full control, but you own the uptime, scaling, and patching.
2. Cloud-managed gateways — AWS API Gateway, Azure API Management. Good if you're already committed to that cloud, but they add their own configuration model and pricing quirks to learn.
3. API-as-a-service layers — purpose-built for a specific integration problem, like turning a subscription-based AI tool into a proper API.

That third category matters more than it used to, because "microservices" increasingly includes services that call external AI providers, and those providers often ship consumer products, not clean APIs. If one of your services needs to call Claude, SubToAPI sits in that exact gap: it takes your existing Claude access and exposes it as a standard HTTPS endpoint with its own API keys (sub_live_...), streaming, tool use, and usage metadata per key. Your internal gateway routes /ai/* to it like any other backend, and it doesn't need to know or care that the underlying provider is a chat subscription instead of a native API product.

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4",
    "max_tokens": 500,
    "messages": [{"role": "user", "content": "Summarize this ticket."}]
  }'

From your gateway's perspective, this is just another upstream service with a standard request/response contract — see /docs/messages for the full schema and /docs/streaming if that service needs token-by-token output.

When to Skip the Gateway

An API gateway isn't free. It's another network hop, another piece of infrastructure to monitor, and another potential single point of failure. If you have two or three services and one client, a gateway is probably overkill — a simple reverse proxy or even direct calls might be enough.

The signal that you actually need one is duplication: if you notice the same auth check, the same rate-limiting logic, or the same logging boilerplate showing up in multiple services, that's the point where centralizing it behind a gateway starts paying for itself.

Getting Started Without Overbuilding

Start with the minimum: routing, TLS termination, and authentication. Add rate limiting once you have real traffic patterns to base limits on. Add request transformation and response aggregation only when a specific client actually needs it — don't build generic transformation logic speculatively.

If part of your gateway's job is fronting an AI-powered service, you can be running with an application API key in minutes via /docs/quickstart, rather than building a custom proxy for a chat-based tool. Check /pricing if you need to plan for team seats across multiple services calling the same key pool, or /signup to start a free trial.

FAQ

Is an API gateway the same as a load balancer? No. A load balancer distributes traffic across identical instances of one service. A gateway routes requests to different services based on path, host, or headers, and typically adds auth, rate limiting, and transformation on top.

Does every microservice need its own gateway? No — one gateway (or a small number of BFFs) usually fronts many services. Putting a gateway in front of each individual service just recreates the problem it's meant to solve.

Can an API gateway become a bottleneck? Yes, if it's under-provisioned or doing too much synchronous work (like heavy transformation) on every request. Scale it horizontally, keep transformation logic light, and push heavier processing into the services themselves.