What Is an API Gateway in Microservices?
What Is an API Gateway in Microservices?
An API gateway in microservices is a single entry point that sits between clients and a collection of backend services. Instead of a mobile app or frontend calling ten different services directly, it calls one gateway, and the gateway routes each request to the right service, applies cross-cutting rules, and sends back a unified response.
The core problem it solves: microservices architectures split one application into many small, independently deployed services (users, orders, payments, notifications, and so on). Without a gateway, every client has to know where each service lives, handle authentication separately for each one, and deal with the operational mess of calling dozens of endpoints. The gateway hides that complexity behind one stable interface.
Why Microservices Need a Gateway
As a system grows from three services to thirty, the cost of exposing each one directly grows with it. A gateway centralizes the things that would otherwise be duplicated across every service:
- Routing — mapping incoming paths like
/orders/or/users/to the correct backend service. - Authentication and authorization — validating API keys, JWTs, or OAuth tokens once, instead of in every service.
- Rate limiting and quotas — protecting backend services from being overwhelmed by a single noisy client.
- Request/response transformation — normalizing formats, stripping internal fields, adding headers.
- Aggregation — combining data from multiple services into one response so the client doesn't make several round trips.
- Observability — logging, metrics, and tracing in one place instead of scattered across services.
Without this layer, each microservice team ends up reimplementing auth, rate limiting, and logging on its own — inconsistently, and with more bugs.
A Basic Example
Imagine a system with an orders-service and a users-service. Without a gateway, a client hits both directly:
GET https://orders.internal.company.com/orders/42
GET https://users.internal.company.com/users/7With a gateway, the client only ever talks to one host:
GET https://api.company.com/orders/42
GET https://api.company.com/users/7Behind the scenes, the gateway resolves /orders/ to the orders service and /users/ to the users service. If the orders service gets split into orders-read and orders-write later, the client's URL never changes — only the gateway's routing config does.
API Gateway vs. Load Balancer
These two are often confused because both sit in front of backend infrastructure, but they solve different problems:
| | Load Balancer | API Gateway | |---|---|---| | Primary job | Distribute traffic across replicas of the same service | Route and manage traffic across different services | | Layer | Usually operates at the network/transport layer (L4) or basic HTTP (L7) | Operates at the application layer, understands API semantics | | Auth | Rarely handles auth | Commonly handles auth, rate limiting, quotas | | Awareness | Doesn't know about individual endpoints or business logic | Knows about routes, versions, and API contracts |
In practice, a load balancer often sits behind the gateway, distributing requests across instances of a single service once the gateway has already decided which service should handle the request.
Common Gateway Patterns in Microservices
Edge gateway — one gateway for the entire system, handling all external traffic. Simple to operate, but can become a bottleneck or single point of failure if not scaled properly.
Backend for Frontend (BFF) — separate gateways tailored to specific clients (mobile app, web app, partner API), each exposing a shape of the API suited to that consumer.
Gateway per domain — larger organizations sometimes split gateways along domain boundaries (e.g., a payments gateway, a catalog gateway) to avoid one team's config changes affecting everyone else.
None of these are mutually exclusive — many production systems combine an edge gateway with domain-specific routing rules underneath it.
Building vs. Using a Managed Gateway
Teams generally choose one of three paths:
- Build it themselves with a reverse proxy (nginx, Envoy) and custom middleware for auth and rate limiting.
- Self-host an open-source gateway like Kong, Tyk, or KrakenD, configuring routes and plugins.
- Use a managed API gateway service that handles routing, auth, and observability without infrastructure to run yourself.
The right choice depends on how much operational overhead the team wants to own. A hand-rolled gateway gives full control but means you're responsible for scaling it, patching it, and building rate limiting and auth from scratch. A managed gateway trades some flexibility for less operational burden.
This pattern isn't limited to routing between your own microservices, either — the same gateway concept applies when you need to expose a controlled, authenticated HTTPS interface to an external capability. SubToAPI is a concrete example: it takes your existing Claude access and exposes it as a proper API surface — application keys in the format sub_live_..., streaming, tool use, and usage metadata — so any service in your architecture can call one stable endpoint instead of each team wiring up its own integration.
const response = await fetch("https://api.subtoapi.app/v1/messages", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
model: "claude-sonnet-4",
messages: [{ role: "user", content: "Summarize this order dispute." }]
})
});That request goes through the same conceptual gateway pattern described above: one authenticated entry point, consistent request/response handling, and usage visibility, regardless of which internal service is calling it. See the quickstart and messages docs for the full request/response shape, and pricing for plan details if you're evaluating it for a team.
When You Might Not Need One
A gateway adds a network hop and a piece of infrastructure to maintain. For a system with two or three services and a small internal team, a simple reverse proxy or even direct service-to-service calls might be enough. The gateway pattern earns its keep once you have multiple client types, need centralized auth, or want to stop duplicating rate limiting and logging code across services.
FAQ
Is an API gateway the same as an API management platform? No. A gateway handles routing and request-level concerns like auth and rate limiting. API management platforms typically add a gateway plus a developer portal, API key self-service, billing, and analytics dashboards on top.
Does every microservice need to go through the gateway? Only externally facing calls. Internal service-to-service traffic often bypasses the gateway entirely and uses service discovery or a service mesh instead, since routing every internal call through one gateway can add unnecessary latency.
Can an API gateway become a single point of failure? Yes, if it's not deployed redundantly. In production, gateways are typically run as multiple replicas behind a load balancer, with health checks and failover, so no single instance failing takes down the whole system.