API Gateway Pattern
The API Gateway pattern puts a single managed entry point in front of backend services to handle routing, authentication, rate limiting, and observability. It simplifies clients and secures microservices, but must be designed for high availability.
Best Practice: API Gateway Pattern
An API Gateway is a single entry point that sits in front of a set of backend services and handles concerns that would otherwise be duplicated in every service or pushed onto every client. It routes requests to the right service, terminates TLS, authenticates and authorizes callers, enforces rate limits, and can aggregate responses. Without a gateway, clients must know about every service, and each service must re-implement auth, throttling, and logging. The pattern matters most in microservices, where the number of services makes direct client-to-service communication brittle and insecure. The trade-off is that the gateway can become a bottleneck or single point of failure if not designed for scale.
Step-by-Step Implementation Guidance
- Define what the gateway owns: routing, auth, rate limiting, TLS termination, and aggregation.
- Map external routes to internal services so internal topology stays hidden.
- Centralize authentication and authorization at the gateway.
- Configure rate limiting and quotas to protect backends.
- Add request and response transformation only where genuinely needed.
- Run the gateway in a highly available, horizontally scalable configuration.
- Instrument it with logging, metrics, and tracing for every request.
Common Mistakes Teams Make When Ignoring This Practice
- Exposing internal services directly and duplicating auth in each.
- Putting business logic in the gateway, turning it into a monolith.
- Running a single gateway instance, creating a single point of failure.
- Skipping rate limiting, leaving backends open to overload.
- Using one gateway to serve very different clients instead of combining with BFFs.
Tools and Techniques That Support This Practice
- Kong, NGINX, and Envoy as self-managed gateways.
- AWS API Gateway, Azure API Management, and Google Apigee as managed services.
- OAuth 2.0 / OIDC for centralized authentication.
- OpenTelemetry for gateway-level tracing.
How This Practice Applies to Different Migration Types
- Cloud Migration: Route traffic between legacy and cloud services through the gateway during cutover.
- Database Migration: Keep client-facing routes stable while backend datastores change behind the gateway.
- SaaS Migration: Front external SaaS APIs with your gateway to apply consistent auth and limits.
- Codebase Migration: Use the gateway as a routing seam while extracting services from a monolith.
Checklist
- Define the gateway's responsibilities and boundaries.
- Map external routes to internal services.
- Centralize authentication and authorization.
- Enforce rate limits and quotas.
- Run the gateway highly available and scalable.
- Keep business logic out of the gateway.
- Instrument every request with logs, metrics, and traces.