Architecture
API Gateway
A single entry point in front of many services that handles cross-cutting concerns — routing, auth, rate limiting, TLS termination, request aggregation — so each service need not reimplement them. It simplifies clients and centralises policy. The risk is becoming a bottleneck or a new single point of failure, so keep it thin and highly available.
Purpose
An API gateway is the single front door to a fleet of services: it routes requests, terminates TLS, authenticates callers, enforces rate limits and can aggregate several backend calls into one response. It exists so cross-cutting policy lives in one place instead of being reimplemented in every service.
When to Use It
Essential in microservice systems facing external clients — mobile apps should not know your internal topology. Also the natural seat for API-key management, per-tenant quotas, canary routing and centralised request logging.
Trade-offs
Every request now passes through it, so it must be fast and highly available or it becomes the system's bottleneck and single point of failure. The other failure mode is scope creep: business logic drifting into the gateway until it is a monolith in disguise.
Implementation
Use an established gateway (Kong, Envoy-based, or the cloud provider's) rather than building one. Keep it thin — routing, auth, limits, observability — and deploy it redundantly. Validate tokens at the gateway, then pass verified identity downstream in headers services can trust.