Un gateway fino delante de backends que se mueven
Una plataforma tiende a acumular hostnames de API canónicos — un nombre público estable para cada capacidad. La tentación es apuntar cada nombre directamente al servicio gestionado que lo sirve hoy. Eso acopla tu contrato público a un detalle de implementación: el día que un backend se mueve, el nombre público tiene que moverse con él.
El patrón
Pon una sola capa de enrutado fina entre los hostnames canónicos y los backends. Su único trabajo: dado un hostname, resolver el backend actual, reenviar la petición y devolver la respuesta. Sin lógica de negocio. Sin decisiones que no le toque tomar.
Por qué compensa la indirección
El backend al que apunta un hostname pasa a ser configuración, no código. Rotar un servicio — nuevo despliegue, nueva región, una migración de proveedor — se convierte en un cambio operativo en lugar de un redespliegue de todo lo que hablaba con él. Los consumidores siguen usando el mismo nombre canónico y nunca se enteran de que algo se movió.
Mantén enrutado y seguridad como trabajos separados
La disciplina más útil aquí es la contención sobre para qué sirve esta capa. El enrutado es una responsabilidad; los controles que deciden si una petición está permitida son otra. Mantenerlos separados significa que cada uno cambia a su propio ritmo — puedes reapuntar un backend sin tocar una sola regla de acceso, y endurecer una regla sin redesplegar el router.
La lección que generaliza: un nombre público estable es un contrato; trátalo como tal, y mantén lo que lo resuelve lo bastante aburrido como para no estorbar.
Parte de mis notas de infraestructura. Sigue el blog o escríbeme.