In a system made of several backend services, what does a routing gateway do and what problem does it solve for the client?

## What the gateway actually does Gateway routing is a **structural pattern**: instead of every client holding a list of backend service addresses and picking one itself, all clients talk to exactly one network endpoint, the gateway, and the gateway decides, per request, which backend actually handles it. The decision is made by inspecting attributes of the incoming request: - the **URL path prefix** (everything under `/orders/**` goes to the order service, everything under `/catalog/**` goes to the catalog service) - the **Host header** or subdomain - a **custom header** such as `X-API-Version` - or a **query parameter** These matchers live in a **routing table**, a declarative, ordered list of rules, each mapping a matcher to a backend target (a service name, cluster address, or upstream pool). At request time the gateway walks the rules, usually applying longest-prefix-match or first-match-wins semantics, selects a target, and proxies the request there, often rewriting the path (stripping the `/orders` prefix before it reaches the order service) and forwarding response headers and body back to the caller. The gateway typically also hands the selected target off to a load balancer or service-discovery layer rather than a single hardcoded instance, so it answers 'which service' while a separate mechanism answers 'which instance of that service.' ## Why the pattern exists The reason this pattern exists is **topology decoupling**. Without a gateway, every client (a mobile app, a partner integration, another internal service) would need to know the concrete address of each backend it calls, and that address would leak into client configuration, SDKs, and documentation. Any reorganization on the backend, splitting one service into two, merging two into one, renaming a service, moving it to a new cluster or region, would force a coordinated change across every caller. With a gateway in front, the client-visible contract is just the gateway's host plus a stable set of paths; everything about how those paths map to running services is an internal, gateway-side concern that can change independently. This is also what makes the **strangler-fig** migration strategy practical: when peeling functionality out of a monolith into a new microservice, you stand the new service up, add one routing rule redirecting the relevant path to it, and the monolith's own code for that path can be deleted later, all invisible to callers. ## What it costs The trade-off is that gateway routing introduces a mandatory hop and a centralized piece of infrastructure. 1. **Latency.** Every request now traverses one extra network boundary before reaching its real destination, which adds latency (typically single-digit milliseconds for a well-run gateway, but it is non-zero and compounds under chained gateway calls). 2. **A single point of failure.** Because all traffic funnels through it, the gateway must be made highly available and horizontally scalable in its own right; if it is a single instance, it becomes a single point of failure for the entire system regardless of how resilient the backends are individually. 3. **Configuration that can be wrong.** The routing table itself becomes a piece of configuration that must be kept correct, versioned, and observable: a bad rule can silently misroute an entire class of requests, and unlike an in-process bug it may not surface until production traffic hits the wrong service. ## How it fails in production In production, the most common failure modes are: - a routing rule that **matches more broadly than intended** and swallows traffic meant for another rule (an ordering or prefix-overlap bug); - a **stale rule** left pointing at a decommissioned service, producing connection-refused or 502 errors after that service is removed; - and a **rewrite rule** that strips or adds path segments incorrectly, causing 404s at the backend even though the gateway itself reports a successful match. Because the gateway is shared infrastructure, a slow or hung backend can also exhaust the gateway's own connection pool or thread pool if timeouts and isolation are not configured per-route, degrading unrelated traffic that happens to pass through the same gateway process. ## Where you see it Concretely, Kubernetes Ingress resources do exactly this: an Ingress object lists path rules (`/api/orders` -> `orders-service`, `/api/catalog` -> `catalog-service`) that the ingress controller (nginx, an ALB, etc.) evaluates for every inbound request. AWS Application Load Balancer listener rules and Azure API Management route definitions work the same way at the cloud-infrastructure level, and API-gateway frameworks like Spring Cloud Gateway or Netflix Zuul expose it as first-class 'route predicates' in application code. In every case, the value delivered is the same: one stable address for clients, and full freedom for the backend team to reshape what sits behind it.