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, 140 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
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 | ||
GET /users → Read ServicePOST /users → Write Service | • Routes by HTTP method (GET, POST, PUT, DELETE) • enables CQRS patterns where reads and writes target separate backends | ||
HTTPRoute → backend Service:8080GRPCRoute → backend Service:50051 | • Standard Kubernetes successor to Ingress: role-oriented model (GatewayClass → Gateway → HTTPRoute) • supports native path, header, and weight matching with GRPCRoute for gRPC-specific rules. | ||
/search?region=us-east → US Service/search?region=eu-west → EU Service | • Routes based on query string parameters • useful for region-based or feature-flag routing | ||
$default → Fallback handler | • Handles requests that match no defined route • typically returns 404 or routes to a generic error handler |