An API gateway is a single entry point for all client requests to a set of backend services. It sits in front of your microservices and handles the cross-cutting work every API needs (authentication, rate limiting, routing, logging), so each service doesn't have to. Examples: Kong, AWS API Gateway, Apigee, Envoy-based gateways, Nginx configured as a gateway.
In simple words
The main gate of an office campus: the guard checks your ID, makes sure you're allowed in, limits how many visitors enter per minute, and tells you which building to go to. The buildings themselves don't each need their own guard.
One entry point handles the cross-cutting work; services behind it stay focused on business logic.
Why It Exists
With microservices, a mobile app might otherwise need to know the addresses of the user service, order service, payment service and more, and each of those would reimplement auth and throttling. The gateway gives clients one stable address and one place for shared policy.
How It Works
mobile / web / partners
|
+-------------+ 1. terminate TLS
| API gateway | 2. authenticate (JWT / API key / OAuth)
+-------------+ 3. rate-limit per user or key
| | | 4. route by path/version, maybe transform
v v v 5. log, trace, collect metrics
users orders payments (internal services)
Routing: /v1/orders/* → order service; versioning and canary routing.
Auth: validate tokens once; forward the user identity to services.
Rate limiting and quotas: protect backends; enforce plan limits for API customers.
Aggregation (sometimes): one client call fans out to several services and the gateway combines the results, saving mobile round trips (the "Backend for Frontend" pattern takes this further with one gateway per client type).
Use when you have several services behind one public API, external API consumers, or policies that must be applied uniformly.
Avoid putting business logic in it: a gateway full of per-feature code becomes a bottleneck that every team must change.
It adds a network hop and is on every request, so it must be fast, horizontally scaled and highly available.
Key Pointers
API gateway = reverse proxy specialised for APIs: auth, rate limits, routing, observability.
Keeps cross-cutting concerns out of each service.
Keep it thin; business logic belongs in services.
Gateway handles north-south (client→services) traffic; a service mesh handles east-west (service→service).
Follow-up Questions
API gateway vs load balancer?
A load balancer spreads traffic across instances of a service and checks health. A gateway understands the API: who the caller is, what they're allowed, which service handles the path, how many calls they have left. Gateways usually sit behind or include load balancing.
Where do you enforce rate limits: gateway or service?
Coarse per-client limits at the gateway (cheap rejection before work is done); fine-grained, business-specific limits (e.g. "5 OTPs per phone per hour") in the service that understands them.
What happens if the gateway goes down?
Everything behind it is unreachable, so run multiple stateless instances across zones behind a load balancer, keep its per-request work small, and store rate-limit counters in a shared fast store.