One thin gateway in front of moving backends

A platform tends to accumulate canonical API hostnames — a stable public name for each capability. The temptation is to point each name straight at whatever managed service serves it today. That couples your public contract to an implementation detail: the day a backend moves, the public name has to move with it.

The pattern

Put one thin routing layer between the canonical hostnames and the backends. Its only job: given a hostname, resolve the current backend, forward the request, return the response. No business logic. No decisions it does not have to make.

Why it is worth the indirection

The backend a hostname points to becomes configuration, not code. Rotating a service — new deployment, new region, a provider migration — turns into an operational change instead of a redeploy of everything that talked to it. Consumers keep using the same canonical name and never learn that anything moved.

Keep routing and security as separate jobs

The most useful discipline here is restraint about what this layer is for. Routing is one responsibility; the controls that decide whether a request is allowed are another. Keeping them separate means each can change on its own cadence — you can re-point a backend without touching a single access rule, and tighten a rule without redeploying the router.

The lesson that generalizes: a stable public name is a contract; treat it as one, and keep the thing that resolves it boring enough to stay out of the way.

Part of my infrastructure notes. Follow the blog or contact me.