Think of a big mailroom with one street address. Mail for accounting, mail for legal, mail for the warehouse — it all arrives at the same loading dock, and a sorter reads each label and sends it to the right department. The senders outside never need to know where any department actually sits inside the building.
Gateway Routing is that mailroom for your services. Clients send everything to one endpoint, and the gateway reads each request and forwards it to whichever backend should handle it — by path, by hostname, or by version.
The problem
When clients call services directly, they have to know your internal layout: which service owns /orders, where /users lives, which host serves the new v2 API. That knowledge gets baked into every mobile app and browser you ship. The moment you split a service in two, rename one, or move it to new infrastructure, every client breaks until it's updated — and you can't update apps already on people's phones.
Versioning makes it worse. Rolling out a new release means somehow getting clients to point at the new endpoint, with no clean way to send just a fraction of traffic to it first to make sure it's healthy.
ClientHas every backend's address baked in — which host owns /orders, /users, the v2 API. Shipped into apps already on people's phones.
BackendSplit, renamed, or moved to new infrastructure, its address changes — and every client pointing at the old one breaks until it's updated.
How it works
The gateway publishes a single, stable endpoint and keeps the map of what lives where. When a request arrives, it inspects the path, host, or headers and forwards it to the matching backend: /orders/* goes to the orders service, /users/* to the users service, a v2 header or path prefix to the new version. The routing rules live entirely in the gateway's config, so clients stay blissfully unaware of the topology behind the door.
Because you control routing centrally, you can change it without redeploying a single client. Move a service and you just update one rule. Want a canary release? Send 5% of traffic to v2 and 95% to v1, then shift the dial as confidence grows. The diagram below shows requests with different paths arriving at one gateway and being forwarded to different backends.
- Routing gatewayReads each request's path, host, or headers and forwards it to the matching backend — rules live here, not in clients.
- BackendA distinct service or version; you can move, split, or canary one by editing a routing rule, with no client change.
Routing rules are a deployment superpower. Because the gateway decides where traffic goes, you get blue-green and canary releases almost for free: stand up the new version alongside the old, route a trickle of traffic to it, watch the metrics, then ramp up or roll back by editing one rule — no client ever notices.
When to use it
Routing is worth it as soon as you have more than a couple of backend services that external clients would otherwise need to address individually, or when you want to evolve your service layout and versions without breaking clients. It's a foundational job of an API gateway and the natural companion to gateway aggregation and gateway offloading — route the request, combine what's needed, handle the shared concerns.
It's distinct from load balancing: a load balancer spreads requests across identical servers, while routing sends them to different services based on what the request says. For a single-service app there's nothing to route, so skip it — but the moment your backend becomes a collection of services, a routing front door is what keeps clients sane.