// Communication & Integration · 07
API Gateway
One front door. Auth, routing, and rate limits handled in one place.
How it fits together
- Client uses / calls API gateway (1 request)
- API gateway uses / calls Orders (2 /orders/**)
- API gateway uses / calls Catalog (2 /catalog/**)
- API gateway uses / calls Users (2 /users/**)
Spot it
- Clients hold URLs for a dozen services
- Every service reimplements token validation
- Internal services are exposed to the internet
It costs
An extra hop, and a shared component every request depends on.
Go deeperThe full explanation and what to ask for · 1 min readExpandCollapse
A gateway is a reverse proxy at the edge: clients see one host, and it routes each request to the right service. Cross-cutting concerns such as TLS, authentication, rate limiting, CORS and request logging are handled there once instead of in every service.
The classic mistake is letting it grow business logic, orchestration and per-team transformations until every release has to touch it. Keep it to routing and policy. It sits on every request path, so run several instances and watch its latency.
One gateway for every kind of client tends to bloat with client-specific needs; splitting it per client type gives a backend for frontend. The gateway handles north-south traffic from outside; a service mesh handles east-west traffic between services.
Ask for it
- reverse proxy
- route / upstream
- TLS termination
- token validation
- rate limiting
- north-south traffic
Put a reverse-proxy gateway (Kong, NGINX, Envoy, Traefik) in front of Orders, Catalog and Users: route /api/{service}/** to each upstream, validate JWTs with a policy per route, add per-client rate limiting, forward a correlation id and expose health checks. Keep business logic out of it.