Topic 11.3
API Gateway in Microservices
In one line
The single entry point: routing, auth, rate limiting, and keeping clients independent of service topology.
Think of it like this
A hotel's single front desk that routes every guest request to the right department (room service, housekeeping, spa) without the guest needing to know which internal team handles what.
Key ideas
- 01
Gateway routes /orders/* → order-service, /users/* → user-service, hiding instaernal topology from clients.
- 02
Cross-cutting concerns centralize: authN/authZ, rate limits, quotas per client, request logging, response shaping.
- 03
It can aggregate: one client call → gateway fans to 3 services (BFF) — convenience at a latency cost.
- 04
Gateway must be stateless + replicated; it's a choke point — scale it, monitor it, circuit-break downstream.
- 05
Alternatives: per-service prefixes (no gateway), service mesh (internal), Backend-for-Frontend (one per client family).
- 06
Interview: 'one gateway for auth+quotas, thin by design — aggregation only where latency is acceptable'.
Java / Spring map
- →
Spring Cloud Gateway routes + filters; Spring Security at the gateway; Resilience4j circuit breaker beside it.
Explain without notes
What's the failure mode when the gateway does API aggregation and one downstream is slow — and the fix curve?
Practice
Route table + quota policy + auth flow for a 3-service checkout API.
Trade-offs
- ↔
Central gateway = one place to break + one more hop; cost traded for operational leverage.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can design a gateway config: routing, auth, quotas, health, and its own scaling.