An API Gateway serves as the centralized entry point between client applications and backend microservices, handling routing, security, transformation, and management at scale. In modern cloud-native architectures, gateways decouple clients from distributed services — enabling independent evolution of microservices while maintaining consistent external contracts. The gateway pattern consolidates cross-cutting concerns like authentication, rate limiting, caching, and observability into a single layer rather than duplicating this logic across every service. In 2026, gateways are also expanding into AI/LLM traffic management, where token economics, semantic caching, and content guardrails demand purpose-built patterns beyond traditional request-response handling — making gateway architecture decisions more consequential than ever.
What This Cheat Sheet Covers
This topic spans 19 focused tables and 149 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Core Routing Patterns
Routing is the gateway's primary function: matching incoming requests to the right backend by inspecting paths, headers, methods, or weights. Getting routing right — especially choosing between path-based, header-based, and Kubernetes-native HTTPRoute approaches — determines how cleanly your microservices can evolve independently while sharing a single external entry point.
| Pattern | Example | Description |
|---|---|---|
/api/v1/users → User Service/api/v1/orders → Order Service | • Routes requests to different backends based on URL path prefixes • the simplest and most common routing strategy, enabling service isolation under a single domain | |
api.example.com → Public APIinternal.example.com → Internal API | • Routes based on HTTP Host header• allows different APIs or versions to share infrastructure while appearing as distinct services | |
90% → v1 backend10% → v2 backend | • Distributes traffic proportionally between backend versions • enables gradual rollouts and canary testing with minimal blast radius | |
X-API-Version: 2 → v2 backendUser-Agent: mobile → Mobile Service | • Routes traffic based on HTTP header values • enables A/B testing, version targeting, and client-type-specific backends |