Topic 9.7
API Gateway
In one line
The L7 front door for APIs: routing, auth, quotas, aggregation, and the single integration point for clients.
Think of it like this
Airport security and check-in, which every passenger passes through regardless of which airline or gate they're headed to. One single checkpoint that verifies your ticket, checks your bags, and then routes you to the right terminal.
Key ideas
- 01
Gateway = reverse proxy for a service fleet PLUS policy: authn/authz, rate limits, request validation, routing, response transformation.
- 02
Client benefits: ONE endpoint to integrate ('/v1/*' → routed internally), SDK simplicity.
- 03
Ops benefits: quotas per client, circuit-breaking downstream, observability hooks in one place.
- 04
Aggregation: graphql-style one gateway call fanning to several services (BFF pattern) — powerful, latency-heavy.
- 05
Gateway vs Service Mesh: gateway = external edge; mesh (istio/linkerd) = internal service-to-service with the same trick.
- 06
Interview: gateways are the 'and then all requests pass through a gateway for auth and quotas' sentence every HLD wants.
Java / Spring map
- →
Spring Cloud Gateway; Zuul legacy; Kong/Envoy/AWS API Gateway are the infra answers.
Code & diagrams
Explain without notes
Name two things the gateway must NOT do (that tempt everybody) and why.
Practice
Design the gateway route table + quota policy for your food-delivery APIs.
Trade-offs
- ↔
Centralization = easy policy, single choke point to scale and monitor; keep gateways stateless + replicated.
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 place a gateway at the edge with concrete responsibilities and name its scaling story.