API Gateway: When and What For
An API gateway centralizes cross-cutting concerns (auth, rate limit, routing, transformation). It's a force multiplier when used narrowly and a god-object when used as an integration platform.
Deep dive
Good fits
- Token validation + authn at the edge.
- Per-route rate limiting and quota.
- TLS termination + WAF integration.
- BFF (backend-for-frontend) routing.
Bad fits
- Business logic, data transformation, orchestration → use proper services.
- "Single source of API truth" → version-skew nightmares.
Build vs buy
- Cloud-native (APIM, AWS API Gateway): great for managed services, slow to iterate, opaque cost.
- Self-managed (Kong, Tyk, Envoy + custom plugins): more control, more ops.
- Service-mesh sidecar (Istio/Envoy): consistent L7 inside the cluster, but not a replacement for an external edge.
Real-world example
From productionTeam used the API gateway as the integration layer. Every new service required a gateway PR + config deploy. Lead time per change: 2 weeks. Refactored: gateway only does auth/rate-limit/routing; transformations moved into BFFs. Lead time per service change: <1 day.
Interview questions
1 senior-levelQ1What belongs in an API gateway?▾
Cross-cutting concerns that benefit from centralization: TLS, authn, rate limiting, basic routing. What doesn't: business logic, data composition, orchestration — those go in services or BFFs.
Common mistakes
Putting business rules in gateway scripts.
Single shared gateway for many teams with no isolation.
Trade-offs
Edge gateway adds a hop and a SPoF — make it HA and observable.