Entrevista de diseño de sistemas: Diseñar un API Gateway multirregión

Problema y casos de uso

Diseñe el punto de entrada público para 300 servicios de backend. Alcanza picos de 500 000 solicitudes por segundo en tres regiones activas y contiene unas 20 000 definiciones de rutas. El gateway termina TLS, autentica a los emisores, aplica autorización y cuotas generales, normaliza solicitudes, selecciona un upstream, admite canaries ponderados y emite métricas y trazas. Asuma un objetivo de disponibilidad del 99.99% y menos de 10 milisegundos de latencia p99 añadida por el gateway. Estos son datos de entrada para la entrevista, no afirmaciones sobre un producto.

Los cambios en rutas y políticas deben llegar a los gateways en buen estado en un plazo de 30 segundos. Las revocaciones de credenciales de emergencia necesitan una vía más rápida. Una mala configuración no debe tumbar todas las regiones, y un plano de control no disponible no debe impedir que los gateways sigan prestando servicio con la última configuración válida conocida. La lógica de negocio del backend, la composición de respuestas, la orquestación de flujos de trabajo de larga duración y la autorización específica de la aplicación permanecen fuera del gateway.

Esta es una pregunta de diseño de sistemas de nivel senior porque el trabajo crítico se sitúa entre los componentes: definir la ruta crítica de las solicitudes (hot request path), separar la configuración del tráfico, acotar el comportamiento ante fallas y demostrar que una entrada compartida globalmente no es un punto único de falla.

Qué está evaluando el entrevistador

Una respuesta sólida primero separa el plano de datos (data plane) del plano de control (control plane). Los procesos del gateway regional atienden solicitudes a partir de una instantánea (snapshot) local inmutable. El plano de control valida, versiona, almacena y distribuye los cambios de rutas y políticas. Si un candidato incluye una consulta a una base de datos o una búsqueda de configuración remota en cada solicitud, ni se cumple el objetivo de latencia ni se aísla la falla del plano de control.

El entrevistador también espera un límite claro para las responsabilidades del gateway. La terminación TLS, la verificación de identidad, la coincidencia de rutas, las políticas generales, la limitación de tasa (rate limiting), los encabezados, los tiempos de espera (timeouts) y la telemetría son aspectos transversales. Las comprobaciones de inventario, las decisiones de pago y los permisos a nivel de objeto pertenecen a los servicios. Un gateway universal que ejecuta plugins de negocio arbitrarios se vuelve difícil de probar y peligroso de desplegar.

La capacidad debe ser recalculable. A 500 000 solicitudes por segundo, una solicitud entrante promedio de 2 KiB equivale a unos 500,000 × 2 KiB ≈ 0.95 GiB/s antes de la sobrecarga del protocolo. Si una instancia de gateway evaluada mediante benchmarks mantiene de forma segura Q solicitudes por segundo en el p99 requerido, la flota necesita al menos ceil(500,000 / Q) instancias, más capacidad adicional para la pérdida de una región. La pérdida de una de las tres regiones equivalentes eleva cada región superviviente de aproximadamente 167 000 a 250 000 solicitudes por segundo, un incremento del 50%. La planificación de capacidad debe incluir ese estado.

Por último, una respuesta completa cubre la seguridad de la configuración, el enrutamiento regional, la propagación de sobrecargas, los reintentos, la observabilidad y la degradación explícita. Decir "despliéguelo en varias regiones" no explica cómo se mueve el tráfico, cómo cambia el estado o qué permanece disponible durante una partición.

Preguntas de aclaración antes de responder

• ¿Quiénes son los clientes? Asuma clientes públicos web, móviles y socios comerciales que utilizan APIs HTTP. El tráfico interno de servicio a servicio puede utilizar un ingress separado o una política de service mesh.
• ¿Cuál es la unidad de disponibilidad? Una región contiene instancias de gateway distribuidas en al menos tres zonas de falla. Las tres regiones son activo-activo, y el enrutamiento global elimina una región que no esté en buen estado.
• ¿Son las rutas independientes por nombre de host, ruta y método? Sí. El orden de coincidencia debe ser determinista y las definiciones de ruta ambiguas se rechazan antes de su publicación.
• ¿Qué políticas se ejecutan de forma síncrona? Verificación de firmas, coincidencia de rutas, comprobación de autorización general, cuotas, límites de solicitudes y transformación de encabezados. El gateway nunca consulta datos de negocio para tomar una decisión.
• ¿Qué tan actualizada debe estar la configuración? Los cambios normales convergen en 30 segundos. Los gateways informan sobre la versión que tienen aplicada. Las revocaciones de seguridad utilizan tiempos de vida de tokens cortos o una lista de denegación pequeña distribuida por separado en lugar de forzar una reconstrucción completa de la instantánea.
• ¿Qué tan exactas son las cuotas entre regiones? El diseño predeterminado utiliza cuotas regionales asignadas a partir de un presupuesto global. Un contador global estrictamente exacto añadiría una dependencia interregional a cada solicitud y debe justificarse por separado.
• ¿Puede el gateway reintentar solicitudes? Solo solicitudes idempotentes, con un presupuesto de reintentos pequeño, tras comprobar que el primer intento no fue aceptado. Las escrituras no idempotentes requieren una clave de idempotencia de la aplicación o ningún reintento automático.
• ¿Qué queda excluido? La mitigación de DDoS previa al gateway, la implementación de servicios, la replicación de bases de datos y las transacciones a nivel de aplicación son sistemas independientes.

Marco de respuesta de 30 segundos

"Ubicaría una flota de gateways sin estado en cada una de las tres regiones activas detrás de un enrutamiento global consciente del estado de salud. Cada solicitud permanece en una sola región: el gateway termina TLS, verifica la identidad desde una caché de claves local, busca coincidencias en una instantánea inmutable de rutas, aplica políticas generales y una cuota regional, y luego selecciona un upstream en buen estado en la misma región. Un plano de control independiente valida cada configuración, le asigna una versión, la despliega de forma canary en una pequeña cohorte de gateways y la activa atómicamente; los gateways continúan prestando servicio con la última instantánea válida conocida si ese plano falla. Dimensionaría cada región para soportar el aumento de carga del 50% tras la caída de una de las tres regiones iguales, limitaría los reintentos y las colas para evitar la amplificación de la sobrecarga, y monitorizaría la latencia añadida, los resultados de rutas, el estado del upstream, las versiones de configuración y la conmutación por falla regional".

Análisis detallado paso a paso

El sistema tiene cuatro capas. La gestión del tráfico global envía al cliente a una región cercana y saludable. Un balanceador de carga regional distribuye el tráfico entre instancias de gateway sin estado en múltiples zonas. El plano de datos reenvía las solicitudes a los endpoints de servicio de la misma región como proxy. El plano de control almacena la configuración deseada, la compila en instantáneas versionadas y distribuye dichas instantáneas de forma independiente a la ruta de las solicitudes. Microsoft documenta los gateways como puntos de entrada centralizados para el enrutamiento y las cuestiones transversales, y su modelo de gateway administrado y autohospedado separa de forma similar la configuración administrada centralmente del tráfico distribuido en tiempo de ejecución.

El flujo normal de una solicitud es:

1. DNS global o Anycast selecciona una región en buen estado. El balanceador de carga regional selecciona una instancia de gateway.
2. El gateway termina TLS, aplica límites de tamaño de solicitud y de conexiones, y adjunta un ID de solicitud.
3. Verifica un token firmado utilizando metadatos del emisor y claves públicas en caché. Nunca llama al proveedor de identidad en cada solicitud.
4. Un comparador compilado utiliza el host, el método y la ruta normalizada para seleccionar una ruta de la instantánea activa.
5. La cadena de políticas aplica alcances generales, cuota regional, encabezados, tiempo de espera y selección canary opcional.
6. El gateway elige un endpoint en buen estado a partir del descubrimiento de servicios en caché local y reenvía la solicitud con un límite de tiempo acotado.
7. Registra el resultado, la latencia, el ID de ruta, el clúster upstream, la versión de configuración y el contexto de traza, y luego transmite la telemetría fuera de la ruta crítica.

Una definición de ruta puede mantenerse declarativa:

Route {
  id: string
  host: string
  methods: string[]
  path_template: string
  upstream_cluster: string
  auth_policy_id: string
  quota_policy_id: string
  timeout_ms: uint32
  retry_policy: { max_attempts, retryable_statuses }
  traffic_split: [{ revision, weight }]
}

La API de control acepta una revisión deseada con una clave de idempotencia y devuelve un ID de revisión. La validación comprueba el esquema, las coincidencias conflictivas, los clústeres referenciados, la propiedad de los certificados, los límites de políticas y las combinaciones de reintento inseguras. Un compilador genera una instantánea inmutable con estructuras de coincidencia preconstruidas. La publicación avanza mediante validación, comparación en la sombra (shadow comparison), una cohorte canary pequeña, una zona, una región y, finalmente, todas las regiones. Cada gateway descarga la instantánea, verifica la suma de comprobación y la firma, la construye fuera del hilo de solicitudes y conmuta un puntero atómico. Las solicitudes en curso finalizan con la instantánea anterior. Si las comprobaciones de salud fallan, la cohorte revierte a la versión anterior.

El mayor cuello de botella es la seguridad de la configuración a escala de flota. Enviar actualizaciones mutables individuales puede dejar inconsistentes las versiones de rutas, políticas y certificados. Una instantánea versionada hace explícita la unidad de activación. Los gateways guardan la última instantánea verificada en el disco local o en almacenamiento de nodo duradero, retienen al menos una versión anterior y exponen desired_version, downloaded_version y active_version. Una interrupción del plano de control congela los cambios, pero no el tráfico. Una instantánea corrupta o incompleta se rechaza. Una revocación de emergencia no debería esperar a que se recompilen las 20 000 rutas: las credenciales de corta duración limitan la exposición, mientras que una lista de denegación pequeña y firmada tiene su propio canal de distribución rápido y caducidad.

Para la capacidad, evalúe la cadena completa de políticas en lugar de un proxy inverso vacío. Si una instancia probada mantiene 8000 solicitudes por segundo en el p99 objetivo, el tráfico pico necesita ceil(500,000 / 8,000) = 63 instancias antes del margen de maniobra. Con tres regiones iguales, la falla de una región deja 250 000 solicitudes por segundo por sobreviviente, o 32 instancias según ese benchmark; desplegar entre 40 y 45 por región proporciona margen operativo. La cifra es ilustrativa y debe sustituirse por mediciones que utilicen TLS real, verificación de tokens, tamaños de payload, registro y latencia del upstream.

El gateway debe descartar carga en lugar de acumularla. Establezca límites en solicitudes concurrentes, conexiones, cuerpos de solicitud, colas por ruta y búferes de telemetría. Propague plazos límite a los upstreams. El cortocircuito (circuit breaking) evita que un servicio con fallas consuma todas las conexiones del gateway. Reintente únicamente un conjunto restringido de fallas idempotentes, use fluctuación aleatoria (jitter) y cargue cada intento a un presupuesto de reintentos. Cuando un upstream está saturado, devolver 503 con prontitud es más seguro que crear una cola ilimitada que agote el gateway compartido.

La autenticación utiliza verificación local para tokens firmados. Las claves públicas se actualizan de forma asíncrona, se solapan durante la rotación y mantienen un conjunto válido conocido durante un período acotado. Si un token es opaco y la introspección es obligatoria, almacene en caché resultados positivos breves y defina el comportamiento de apertura ante fallas (fail-open) o cierre ante fallas (fail-closed) según el riesgo de la ruta; esa dependencia altera el cálculo de disponibilidad. La propiedad de objetos y la autorización de negocio permanecen en el servicio porque el gateway carece del estado de dominio autoritativo.

Las cuotas son regionales en la ruta crítica. Un asignador global divide el presupuesto de un tenant en concesiones cortas para las regiones, y los almacenes de datos regionales toman decisiones atómicas. Esto evita que una partición multiplique una cuota global ilimitada, pero una región aislada solo puede consumir su concesión. Si las regiones independientes continúan admitiendo solicitudes y reconcilian más tarde, la disponibilidad mejora aunque se vuelve posible una sobre-admisión. El propietario del producto debe elegir ese límite. La implementación detallada del algoritmo token-bucket se delega al subsistema de rate-limiter en lugar de reconstruirse dentro de cada gateway.

AWS documenta tanto el enrutamiento de conmutación por falla activo-pasivo como el enrutamiento ponderado activo-activo para gateways multirregión. En este caso, el esquema activo-activo reduce el riesgo de una conmutación en frío. La salud es jerárquica: la salud de la instancia elimina un proceso, las señales zonales drenan una zona, y las sondas sintéticas de extremo a extremo junto con las tasas de error regionales eliminan una región. El desvío de tráfico es gradual siempre que sea posible. Los backends regionales y sus almacenes de datos también deben estar listos; mover solo el gateway no puede hacer que un servicio no disponible pase a estar saludable.

La observabilidad requiere métricas de latencia p50/p95/p99 añadida por el gateway, tasas de solicitudes y errores por ruta, fallas de TLS y autenticación, resultados de cuotas, conexiones activas, profundidad de colas, reintentos, estado del circuito, latencia del upstream, salud de los endpoints y retraso en las versiones de configuración. Los registros muestrean el tráfico exitoso pero retienen eventos de seguridad y errores bajo un presupuesto acotado. Las trazas preservan el contexto entrante e inician un span de gateway. Las alertas distinguen la falla del gateway de la falla del upstream para que los operadores no reviertan un gateway saludable debido a un incidente en un servicio.

La alternativa principal es un único gateway universal frente a gateways o BFFs (Backend for Frontend) por cliente o dominio. Una sola flota simplifica la entrada externa y la gobernanza, pero amplía el radio de impacto y fomenta la acumulación de políticas. Múltiples gateways aíslan equipos y comportamientos específicos de clientes, pero duplican las operaciones y requieren controles globales consistentes. Comience con un gateway de plataforma ligero más servicios propios de cada dominio; añada un BFF solo cuando un cliente realmente necesite agregación o un contrato diferenciado. Un service mesh complementa este diseño para el tráfico este-oeste y no reemplaza al gateway público norte-sur.

La verificación incluye pruebas de propiedades de tablas de rutas para una coincidencia determinista, pruebas de compatibilidad de instantáneas, pruebas de carga con capacidad normal y con falla en una región, comparación en la sombra de revisiones antiguas y nuevas, e inyección de fallas para pérdida de conectividad con el plano de control, claves obsoletas, upstreams lentos, contrapresión de telemetría, pérdida zonal y evacuación regional. Un diseño está completo cuando cada falla tiene un estado observable y una respuesta acotada.

Respuesta de muestra de alta calidad

"Ejecutaré flotas de gateways sin estado a través de tres regiones activas y múltiples zonas. El enrutamiento global envía a los clientes a una región cercana y saludable; un balanceador de carga regional distribuye el tráfico entre las instancias de gateway. La ruta crítica termina TLS, verifica la identidad firmada desde una caché de claves local, busca coincidencias con una ruta compilada, aplica autorización general y una cuota regional, elige un endpoint saludable en la misma región y reenvía con un tiempo de espera acotado. La autorización de dominio permanece en el servicio.

La ruta de la solicitud nunca lee de la base de datos de configuración. Un plano de control separado valida los cambios deseados en rutas y políticas, rechaza coincidencias ambiguas y reintentos inseguros, compila una instantánea inmutable y firmada, y la despliega a través de etapas en la sombra, cohorte, zona y región. Cada instancia construye la nueva instantánea fuera del hilo de atención y la reemplaza de forma atómica. Persiste la última versión válida conocida, de modo que una interrupción en el plano de control detiene los cambios sin detener el tráfico. El retraso de versiones y la reversión automática hacen que el despliegue parcial sea visible y reversible.

A 500 000 solicitudes por segundo, 2 KiB de datos entrantes representan aproximadamente 0.95 GiB/s antes de la sobrecarga. Evaluaré la cadena de políticas completa mediante benchmarks para obtener el rendimiento seguro por instancia Q y desplegaré ceil(500,000 / Q) más margen para fallas. Dado que la pérdida de una de las tres regiones iguales incrementa la carga de cada superviviente en un 50%, la capacidad regional y las pruebas de carga incluyen ese estado.

Limitaré las conexiones, la concurrencia, los cuerpos de solicitud, las colas y los intentos de reintento. Los reintentos idempotentes utilizan un presupuesto pequeño; las escrituras no idempotentes requieren una clave de idempotencia o ningún reintento automático. Las cuotas globales se asignan como concesiones regionales cortas, haciendo explícito el compromiso (trade-off) ante particiones. Finalmente, monitorizaré la latencia añadida por el gateway, los resultados de rutas, la salud del upstream, el comportamiento de reintentos y circuitos, las versiones activas de configuración y las sondas sintéticas regionales, para luego probar pérdidas del plano de control, configuraciones erróneas, pérdidas zonales y conmutación regional antes del lanzamiento".

Errores comunes

• Leer rutas o políticas desde una base de datos en cada solicitud → la latencia y la disponibilidad dependerán del plano de control → sirva desde una instantánea local validada y mantenga el último estado válido conocido.
• Poner lógica de negocio en plugins del gateway → los despliegues adquieren un radio de impacto global y la propiedad del dominio se vuelve difusa → mantenga el gateway declarativo y traslade las decisiones de negocio a los servicios o a un BFF justificado.
• Publicar cambios mutables individuales → las rutas, políticas y certificados pueden activarse en combinaciones incompatibles → compile una única instantánea versionada y cámbiela de forma atómica.
• Tratar múltiples instancias como resiliencia suficiente → una sola revisión defectuosa puede romper todas las instancias a la vez → realice canaries por cohorte, zona y región, con controles de salud automáticos y reversión.
• Dimensionar solo para el pico ordinario → las regiones supervivientes se sobrecargarán durante una evacuación → calcule y pruebe el incremento del 50% por región tras la caída de una de tres regiones iguales.
• Reintentar todas las fallas → los reintentos amplifican la sobrecarga y pueden duplicar escrituras → reintente solo casos idempotentes acotados y exija idempotencia de aplicación para escrituras.
• Utilizar una llamada al proveedor de identidad en cada solicitud → la autenticación hereda una dependencia remota síncrona → verifique tokens firmados localmente y actualice claves de forma asíncrona con desfase acotado.
• Dar a cada región una cuota global completa → un tenant puede multiplicar su límite por el número de regiones → asigne concesiones regionales o establezca explícitamente el límite aceptado de sobre-admisión.
• Mover el tráfico del gateway sin verificar los backends → la región seleccionada podría no tener servicios saludables o capacidad de datos → haga que las sondas regionales de extremo a extremo y la preparación del backend formen parte de la conmutación por falla.
• Registrar todo payload exitoso → la telemetría consume recursos de la ruta crítica y puede filtrar datos confidenciales → emita metadatos estructurados de forma asíncrona, muestree éxitos y censure datos sensibles según la política.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Cómo se revierte una mala configuración de rutas sin perder solicitudes?

Mantenga instantáneas inmutables y al menos una versión previamente verificada. Un gateway construye una versión candidata fuera de los hilos de solicitudes, valida su suma de comprobación y referencias, y conmuta atómicamente el puntero activo. Las solicitudes existentes retienen su instantánea anterior hasta completarse. Si la salud de la cohorte empeora, el plano de control marca la revisión como fallida y los gateways vuelven al puntero anterior. La reversión cambia el estado de la configuración; no reinicia toda la flota.

Pregunta de seguimiento 2: ¿Qué sucede si el plano de control no está disponible durante una hora?

El tráfico continúa utilizando la última instantánea válida conocida persistida. Los gateways exponen la antigüedad y versión de dicha instantánea y dejan de aceptar cambios no verificados. Las rotaciones de certificados y claves necesitan una validez solapada lo suficientemente larga para esta condición. Las revocaciones de emergencia utilizan tiempos de vida de token cortos o una lista de denegación compacta firmada por separado. Los operadores pierden la capacidad de realizar cambios durante la interrupción, por lo que las alertas se disparan ante retrasos de distribución mucho antes de que el material existente expire.

Pregunta de seguimiento 3: ¿Cómo se evita duplicar un POST cuando un gateway reintenta?

El gateway no reintenta automáticamente una solicitud no idempotente solo porque la conexión con el upstream haya fallado; el backend podría haber confirmado la operación antes de que se perdiera la respuesta. Para operaciones que deben ser reintentables, el cliente proporciona una clave de idempotencia, y el servicio propietario almacena y devuelve el primer resultado. El gateway solo puede reintentar dentro del plazo límite de la solicitud y con un presupuesto de reintentos pequeño. Los errores de conexión ocurridos antes de que se acepte cualquier byte pueden tratarse por separado si la capa de transporte demuestra ese estado.

Pregunta de seguimiento 4: ¿Elegiría DNS global o Anycast para el enrutamiento regional?

Cualquiera de los dos puede satisfacer la arquitectura. El DNS consciente del estado de salud es operacionalmente más simple, pero las cachés hacen que la evacuación sea gradual. Anycast puede redirigir el tráfico más rápidamente, pero requiere operaciones de red más robustas y sigue necesitando señales de salud de la aplicación. Elegiría el mecanismo que la plataforma ya opere, mediría el tiempo de conmutación por falla y mantendría a los clientes tolerantes a los cambios de endpoints. El diseño del gateway regional no depende de asumir que los cambios de DNS son instantáneos.

Pregunta de seguimiento 5: ¿Cuándo se debe dividir un gateway en múltiples gateways?

Divídalo cuando el aislamiento o los contratos difieran genuinamente: tráfico regulado, dominios operados de forma independiente, o clientes móviles y web que requieran una agregación materialmente diferente. No lo divida únicamente para reflejar cada microservicio, porque los clientes entonces descubrirán la topología interna y las operaciones se multiplicarán. Los esquemas de políticas compartidas, las reglas de identidad, la telemetría y la seguridad de despliegues pueden seguir siendo capacidades de la plataforma incluso cuando las flotas en tiempo de ejecución estén aisladas.