Imagine a hotel with no front desk. To check in you'd have to find the housekeeping office yourself, walk to a separate building for the restaurant, and track down the valet on your own — and you'd need to memorize where each one lives. A front desk fixes this: one counter handles everything, and you never need to know how the back of the house is organized.
An API gateway is that front desk for your backend. Instead of clients reaching into a sprawl of microservices directly, they send every request to one well-known endpoint, and the gateway figures out where it should go.
The problem
When a mobile app or browser talks directly to a fleet of microservices, the client has to know the topology — which service owns which feature, where each one lives, and how to reach it. A single home screen might need the profile, orders, cart, recommendations, and stock services, each at its own public address. Every time you split, rename, or move a service, every client has to be updated.
It gets worse with cross-cutting concerns. Authentication, TLS termination, rate limiting, and logging are needed by every service, so each team ends up reimplementing them — slightly differently, with slightly different bugs. Because every service has a public address, each of those slightly different copies is also a front door an attacker can try. And the client is chatty: one screen costs many round trips over a slow mobile network.
Step through that home screen loading below. Predict how long it takes before you see the answer, then flip to Through a gateway and replay the same screen.
How it works
The fix is to place an API gateway as a single entry point in front of the services. Clients only ever know one address; the gateway holds the map of what lives where and does three common jobs on their behalf:
- Routing — inspect each incoming request and send it to the right backend service based on its path or host (
/orders/*goes to the orders service,/users/*to the user service). The client stays blissfully unaware of the layout behind the door. - Aggregation — for a screen that needs data from several services, the gateway fans out the calls, waits for the responses, and combines them into one payload. The client makes a single request instead of five.
- Offloading — handle the shared concerns at the edge: authentication, TLS termination, throttling, and caching all happen once, in the gateway, so the services behind it don't each have to.
Below, three requests arrive at the same gateway: one is fine, one carries an expired token, and one comes from a script that has blown through its rate limit. Before you step through, predict which of them a backend service will ever see.
Offloading is where a gateway earns its keep. Pushing authentication, TLS termination, and throttling to the edge means you write and harden that logic once. Your backend services get to assume the request is already authenticated and rate-limited, so they can stay small and focused on business logic.
Your gateway validates tokens. A request for /orders/42 arrives with an expired token. What should the Orders service receive?
Combine, don't compute
Aggregation is the job most likely to go wrong, because the merge code sits exactly where a quick fix is tempting. The gateway already holds the user, the cart, and the price for the home screen, so why not apply a promotion right there? Below, you make that call. Pick an answer, follow it through, then flip the switch to see the road you didn't take.
The rule of thumb: a gateway may combine responses — merge them, rename fields, drop what the client doesn't need — but it shouldn't compute answers the business cares about. Once it decides prices, permissions, or eligibility, those rules live in two places, and every change has to squeeze through the one deploy pipeline that every team shares.
It's not a load balancer
Gateways and load balancers both sit in front of your servers, so they're easy to confuse — but they solve different problems. A load balancer spreads traffic across a pool of identical servers; it doesn't care what the request says, only that the next instance gets its fair share.
An API gateway routes to different services based on what the request actually is, and adds logic — auth, aggregation, caching — on the way through. It operates at the application layer and understands paths, headers, and tokens. In practice the two are often layered: a load balancer distributes traffic across several gateway instances, and the gateway then routes onward to the correct service.
Backends for Frontends
A common variation is Backends for Frontends (BFF): instead of one gateway trying to serve every client, you run a tailored gateway per client type — one for the mobile app, one for the web app, maybe one for partners. A phone on a flaky connection wants compact, pre-aggregated responses; a desktop browser can handle richer payloads. A BFF lets each frontend get a shape that fits it, without bloating a single shared gateway with conditional logic for everyone.
The front door is also a chokepoint. Because every request flows through it, an unscaled or unprotected gateway becomes a bottleneck and a single point of failure — if it goes down, your whole API goes dark. Run multiple instances behind a load balancer, keep its logic thin, and protect it with timeouts and a circuit breaker so a slow backend can't drag the gateway down with it.
You run a single gateway instance. During each of its deploys, every API returns errors for a minute, even though all the services behind it are healthy. What's the best fix?
When to use it
Reach for an API gateway once you have more than a handful of services and external clients that would otherwise need to know your internal layout. It shines when you want a single place for auth, TLS, and throttling, or when clients are making many round trips that aggregation could collapse into one.
For a small system with one or two services it's overkill — the indirection costs more than it saves. And keep the gateway disciplined: it should route, aggregate, and offload, not become a dumping ground for business logic. That belongs in the services, often deployed alongside them with a sidecar, so the gateway stays a thin, fast, well-protected front door.