API Gateway
Single entry point for routing, policy enforcement, observability, and traffic control.
📌 Key IdeaAn API Gateway sits in front of services and handles cross-cutting concerns like routing, auth integration, rate limiting, request shaping, and edge observability. It simplifies clients and standardizes platform behavior.
Problem it solves
- Clients calling many services directly create tight coupling and inconsistent behavior.
- Cross-cutting controls (auth, throttling, logging, CORS) get duplicated across services.
- Gateway centralizes ingress policies and makes service boundaries safer and easier to evolve.
Definition
API Gateway is an edge component that receives client requests, applies platform policies, routes to downstream services, and returns normalized responses.
Why It Matters
- Reduces client complexity with one public API surface.
- Improves security and reliability through centralized edge controls.
- Enables consistent observability and operational governance.
Code Variations
1) Route and policy sketchyaml
routes:
- id: orders-read
match: { method: GET, path: /api/orders/** }
upstream: orders-service
policies:
- auth: required
- rateLimit: { key: userId, rps: 20 }
- timeoutMs: 800
- id: orders-write
match: { method: POST, path: /api/orders/** }
upstream: orders-service
policies:
- auth: required
- scope: orders:write
- rateLimit: { key: userId, rps: 5 }Keep route/policy config explicit and version controlled.
2) Safe request lifecycletext
Client request
-> sanitize/validate headers
-> authenticate + authorize
-> apply rate limit / timeout / circuit policy
-> route to service
-> emit metrics + trace + auditDirect-to-services vs API Gateway
| Aspect | Direct Client -> Services | Client -> API Gateway -> Services |
|---|---|---|
| Client complexity | High: multiple endpoints/contracts | Lower: one ingress surface |
| Policy consistency | Service-by-service drift | Centralized and reusable |
| Routing/versioning | Hard to change safely | Managed at edge |
| Observability | Fragmented | Unified ingress metrics/logs/traces |
| Risk | Less edge dependency | Gateway can become critical dependency |
Variations / Implementations
Reverse proxy gateway
Core routing, TLS termination, headers, CORS, and basic traffic controls.
BFF (Backend for Frontend)
Gateway per client type (web/mobile) for tailored payloads and orchestration.
Service mesh + edge gateway
Gateway handles north-south traffic while mesh handles east-west concerns.
Common Mistakes / Anti-Patterns
- Putting all business logic in gateway (turns it into monolith choke point).
- No fallback plan for gateway outages or bad config rollouts.
- Using gateway as only authorization layer and skipping service-level checks.
- No SLOs/alerts for gateway latency, error rates, and policy failures.
Interview Q&A
Quick Cheat Sheet
Primary roleEdge routing + policy enforcement.
Best useMany services, many clients, shared cross-cutting needs.
Key cautionDo not move business logic into gateway.
Must monitorp95 latency, 4xx/5xx, policy-deny rate, upstream failures.