An API gateway serves as the single entry point for client requests in microservices and distributed architectures, managing routing, security, rate limiting, and protocol translation between clients and backend services. This centralized control plane enables consistent policy enforcement across all APIs while decoupling client interfaces from backend implementations. Key to modern cloud-native applications, effective gateway configuration balances security, performance, and developer experience — implementing patterns like request transformation, circuit breaking, and canary deployments ensures resilience while maintaining sub-100ms latency for critical traffic paths. Choosing the right deployment topology — from a centralized edge gateway to sidecar-per-service — is equally important and shapes every other configuration decision.
What This Cheat Sheet Covers
This topic spans 17 focused tables and 186 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Routing Patterns
Path, host, header, and method routing are the foundational building blocks of any gateway configuration. Combining these with weighted and regex routing enables sophisticated traffic shaping without application-layer changes — understanding which dimension to route on determines how cleanly you can evolve your backends.
| Pattern | Example | Description |
|---|---|---|
/api/v1/users → Service A/api/v1/orders → Service B | Routes requests to different backend services based on the URL path, enabling logical API organization and service isolation. | |
api.example.com → Productionstaging.example.com → Staging | • Routes traffic to different backends based on the hostname in the request • useful for multi-tenant or environment-specific routing | |
X-API-Version: v2 → New BackendX-API-Version: v1 → Legacy | • Directs requests to specific services based on HTTP header values • enables A/B testing and gradual migrations without URL changes | |
GET /users → Read ServicePOST /users → Write Service | Maps HTTP methods to different backend integrations, supporting CQRS patterns and read/write separation. | |
90% traffic → v1 10% traffic → v2 | • Distributes traffic proportionally across multiple backends • essential for canary deployments and gradual rollouts | |
/search?region=us → US Service/search?region=eu → EU Service | Routes based on query string parameters for region-specific or feature-flag-driven traffic distribution. |