What does an API gateway actually do, and why put one in front of your microservices?

#The problem without a gateway

Picture a mobile app that needs to show a user's dashboard: their profile, their recent orders, and current inventory availability for items in their cart. Without a gateway, the client calls three separate microservices directly — users-service, orders-service, inventory-service — each on its own host, each requiring its own authentication check, each with its own rate limit, if any. Every client (mobile app, web app, a partner's server) has to know all three addresses, implement the same auth logic three times, and make three round trips where the network is slowest — often over a mobile connection.

Now multiply that by every service you add over the next two years. Cross-cutting concerns — authentication, throttling, logging, TLS termination — end up duplicated inside every service, or worse, inconsistently implemented across them. An API gateway exists to pull all of that out of individual services and into one place, at the edge, in front of everything.

#What a gateway actually does

An API gateway is a reverse proxy purpose-built for this edge role. Four responsibilities show up in essentially every real deployment:

• Routing — it looks at the incoming request's path, host, or header, and forwards it to the correct backend service, often also handling API versioning (/v1/orders vs /v2/orders) and blue/green or canary traffic splits.
• Authentication & authorization — it validates the caller's credentials (an API key, a JWT?, a session cookie) once, at the edge, and either rejects the request outright or forwards it with an internal, service-trusted identity (a validated header, a short-lived internal token). Individual services no longer each reimplement token validation.
• Rate limiting & quotas — it throttles callers per API key, per IP, or per subscription tier, protecting downstream services from being overwhelmed by one noisy client and enabling tiered pricing plans without touching business logic.
• Aggregation (composition) — for endpoints that need data from several services, the gateway (or a Backend-for-Frontend layer built on top of it) can fan a single incoming request out to multiple backend calls and merge the results into one response, so the mobile client above gets its dashboard in one round trip instead of three.

Beyond those four, gateways commonly also handle TLS termination, response caching, request/response transformation (adapting an old client's expected shape to a new backend contract), and centralized observability — every request passes through one choke point, so that is the natural place to emit consistent logs, metrics, and distributed tracing spans.

#Where it stops paying off

A distinction that comes up often in interviews is API gateway versus service mesh — they solve related but different problems, at different layers of the traffic pattern: