Diagrama de arquitectura de API gateway: enrutamiento, autenticación, límites de tasa y BFF

El API gateway es la caja que aparece en todos los diagramas de arquitectura y que pocos explican. Está en el borde y con el tiempo acumula responsabilidades: enrutamiento, autenticación, límites de tasa, reescritura de peticiones y, a veces, reglas de negocio que nunca debió tener. Cuando el diagrama solo muestra una flecha que atraviesa un icono de gateway, nadie sabe cuáles de esas tareas hace, y las preguntas surgen durante un incidente en lugar de en una revisión.

Este artículo construye un diagrama de arquitectura de API gateway para una configuración habitual: una app web, apps móviles y socios detrás de un único gateway, con un backend para cada frontend. Explica qué debe hacer el gateway y qué no, cómo funcionan la validación de tokens y los límites de tasa, y qué etiquetar para que el diagrama responda preguntas reales.

Qué corresponde al gateway

Un balanceador de carga reparte las peticiones entre instancias; no sabe quién es quien llama. Un service mesh gestiona el tráfico entre servicios dentro del sistema. El gateway gestiona el tráfico que entra desde fuera y entiende a los clientes: sus tokens, sus rutas y sus cuotas. Muchos sistemas usan los tres.

Validación de tokens en el borde

En el ejemplo, los clientes inician sesión con el proveedor de identidad y envían un JSON Web Token (RFC 7519) en cada petición. El gateway verifica la firma con las claves públicas del proveedor, que obtiene como documento JWKS y guarda en caché, y comprueba los claims: el emisor (iss), la audiencia (aud) y la expiración (exp).

Las buenas prácticas actuales para JWT de la RFC 8725 merecen seguirse aquí. Una biblioteca debe permitirte especificar los algoritmos permitidos y no debe usar ningún otro, así que configura la lista en lugar de fiarte de la cabecera del token. Cuando un mismo emisor crea tokens para varias aplicaciones, el token debe llevar una audiencia, y cada aplicación debe comprobar que la audiencia es la suya.

Un token válido dice quién es quien llama. No dice qué puede hacer. El gateway puede rechazar un scope que falta, pero sigue siendo el servicio quien decide si este usuario puede cambiar este pedido.

Límites de tasa

Cuenta por cliente, no por dirección IP. Detrás de un NAT, muchos usuarios pueden compartir una dirección, y un solo scraper puede usar muchas. Asocia el límite a la clave de API, al cliente OAuth o al usuario.

Comparte los contadores. Con varias instancias del gateway contando cada una por su cuenta, un límite de 100 por minuto se convierte en 100 por instancia. Un almacén compartido como Redis mantiene un solo contador por cliente para todas las instancias.

Elige un algoritmo y déjalo por escrito. Una ventana fija se reinicia cada minuto y permite ráfagas en el límite entre ventanas. Una ventana deslizante lo suaviza. Un token bucket permite ráfagas cortas hasta un tamaño definido mientras mantiene una tasa media.

Responde con 429. La RFC 6585 define 429 Too Many Requests. La respuesta debe explicar la situación y puede incluir Retry-After, que la RFC 9110 define como una fecha HTTP o un número de segundos de espera. La RFC 6585 no dice cómo identifica el servidor al cliente ni cómo cuenta las peticiones: esa parte es tu diseño, así que ponla en el diagrama. Un borrador del IETF define campos de cabecera estándar RateLimit y RateLimit-Policy, pero en el momento de escribir esto (octubre de 2026) sigue siendo un borrador.

Decide qué pasa cuando cae el almacén de contadores. Fallar en abierto (fail open) mantiene la API disponible sin límites; fallar en cerrado (fail closed) protege los servicios y rechaza el tráfico. Cualquiera de las dos puede ser correcta, siempre que sea una decisión y no un accidente.

Backends para frontends

El patrón Backends For Frontends de Sam Newman sustituye un backend de API de propósito general por un componente del lado del servidor para cada experiencia de usuario. Cada BFF se centra en una sola interfaz y suele mantenerlo el equipo que construye esa interfaz, de modo que el equipo puede cambiar la API a medida que cambian sus pantallas. Un backend compartido y de propósito general tiende a convertirse en un cuello de botella, y el artículo señala que los servicios de agregación en el borde suelen acumular código inflado.

¿Cuántos BFF? Newman atribuye a Stewart Gleadow una regla sencilla: una experiencia, un BFF. Si dos apps ofrecen la misma experiencia y un mismo equipo es dueño de ambas, pueden compartir uno; SoundCloud, por ejemplo, usa un solo BFF para sus apps de escucha de iOS y Android.

Los socios son distintos. Necesitan una API estable y versionada, no una pensada para una pantalla, así que sus rutas van a la API pública de los servicios sin BFF.

El ejemplo: una tienda online

La tienda tiene una app web en React, apps de iOS y Android, y socios que crean pedidos a través de una API. Un WAF filtra el tráfico antes del gateway. El gateway valida los tokens, cuenta las peticiones por cliente en Redis y enruta por prefijo de ruta. Los equipos web y móvil tienen cada uno su BFF, y ambos BFF llaman a los servicios Orders, Catalog y Accounts dentro de la red privada. Las llamadas de los socios van directamente a la API versionada del servicio Orders.

Cómo leerlo:

• De izquierda a derecha, una petición. Un cliente llama al gateway a través del WAF, y el gateway la enruta a un BFF o a la API de socios.
• Las conexiones discontinuas quedan fuera del camino de la petición. La app web inicia sesión con el proveedor de identidad, y el gateway obtiene las claves de firma del proveedor y las guarda en caché.
• Debajo del gateway, Redis guarda los contadores de límites de tasa que comparten todas las instancias del gateway.
• Dentro de la red privada, cada BFF llama solo a los servicios que necesitan sus pantallas.
• El bloque Markdown es la política del gateway: qué comprueba, el límite y qué deja a los servicios.

Qué etiquetar

• Las rutas de cada backend, como prefijos de ruta o hosts.
• La autenticación en cada entrada: el tipo de token, quién lo emite y qué comprueba el gateway.
• Los límites: la clave, el número y la ventana, y qué recibe el cliente de vuelta.
• Los timeouts y los reintentos en el gateway. Los reintentos en el borde multiplican la carga sobre un servicio en apuros.
• El comportamiento ante fallos cuando el proveedor de identidad, el almacén de contadores o un backend no están disponibles.
• La responsabilidad. El equipo de plataforma suele ser dueño de la configuración del gateway; los equipos de interfaz son dueños de sus BFF.

Errores comunes

• Lógica de negocio en el gateway. Las reescrituras y condiciones crecen hasta convertirse en reglas que nadie puede probar. Mantén el gateway ligero.
• El gateway como único control de seguridad. Los servicios que hay detrás no deberían confiar en una petición solo porque llegó. El diagrama de arquitectura zero trust muestra cómo dibujar controles en cada salto.
• Límites solo por IP, que castigan a los usuarios detrás de direcciones compartidas y no detectan a los clientes que rotan direcciones.
• Contadores locales en cada instancia, que multiplican el límite por el número de instancias.
• Un solo BFF para todo, que vuelve a ser un backend de propósito general.
• Un 429 sin detalles. Los clientes que no saben cuánto esperar adivinan, y suelen quedarse cortos.

Para lo que hay detrás del gateway, consulta el diagrama de arquitectura de microservicios. En Kubernetes, el diagrama de Kubernetes Ingress cubre la capa que a menudo se sitúa delante del gateway o sustituye partes de él.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Del pack Modelo C4, añade un Contenedor para la app web y otro para la app móvil, y un Sistema externo para el socio.
3. Del pack Seguridad, añade un WAF y un Proveedor de identidad.
4. Del pack Nube, añade una Puerta de enlace de API, y del pack Datos un nodo Redis para los contadores de límites de tasa.
5. Añade un Marco del pack Básico llamado Private network, con nodos Contenedor del pack Modelo C4 para los dos BFF y los tres servicios.
6. Conéctalos de izquierda a derecha, etiqueta cada ruta con su camino y dibuja discontinuos el inicio de sesión y la obtención de claves. Añade un bloque Markdown del pack Básico con la política del gateway.

El ejemplo usa 14 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Un API gateway es lo mismo que un balanceador de carga? No. Un balanceador de carga reparte las peticiones entre instancias. Un gateway entiende las peticiones de API: rutas, tokens y cuotas. Muchos gateways funcionan detrás de un balanceador de carga.

¿Necesito un service mesh si tengo un API gateway? Resuelven problemas distintos. El gateway gestiona el tráfico que viene de fuera; un mesh gestiona las llamadas entre servicios, por ejemplo con TLS mutuo y reintentos. Dibújalos por separado si usas ambos.

¿Deben los servicios validar el token si el gateway ya lo hizo? Sí, para los claims de los que dependen. El gateway rechaza pronto los tokens malos, y cada servicio sigue autorizando la acción por sí mismo.

¿Cuántos BFF debería tener? Uno por experiencia de usuario. Dos apps con la misma experiencia y el mismo equipo responsable pueden compartir uno.

¿Qué debe contener una respuesta 429? Una explicación breve y una cabecera Retry-After con el número de segundos de espera, para que los clientes esperen en lugar de reintentar de inmediato.

Empieza gratis — un puesto, sin tarjeta de crédito.