API Gateway

Cómo centralizar el acceso a tus microservicios con un punto de entrada único que gestiona enrutamiento, autenticación, rate limiting y transformación de respuestas.

Qué problema resuelve

En una arquitectura de microservicios, los clientes (web, mobile, IoT) necesitan comunicarse con múltiples servicios backend. Sin un punto de entrada centralizado, cada cliente debe:

Conocer las direcciones de todos los servicios
Manejar autenticación con cada servicio individualmente
Lidiar con protocolos y formatos de respuesta diferentes
Implementar lógica de reintentos, timeouts y circuit breaking por su cuenta

Sin API Gateway:
  Mobile App → Servicio Usuarios (auth + datos)
  Mobile App → Servicio Productos (auth + datos)
  Mobile App → Servicio Pedidos (auth + datos)
  Mobile App → Servicio Pagos (auth + datos)
  
  Cada cliente conoce N servicios
  Cada servicio implementa auth, rate limiting, CORS...

Esto genera acoplamiento directo entre clientes y servicios internos, dificulta la evolución independiente de los servicios y duplica preocupaciones transversales (cross-cutting concerns) en cada microservicio.

Cómo funciona

El API Gateway actúa como un proxy inverso que se sitúa entre los clientes y los microservicios. Todas las solicitudes externas pasan por él, y el gateway se encarga de enrutarlas al servicio correcto.

Con API Gateway:
  Mobile App  ─┐
  Web App     ─┤──► API Gateway ──► Servicio Usuarios
  IoT Device  ─┘         │──► Servicio Productos
                          │──► Servicio Pedidos
                          └──► Servicio Pagos
  
  Un solo punto de entrada
  Cross-cutting concerns centralizados

Responsabilidades principales

Responsabilidad	Descripción	Ejemplo
Enrutamiento	Dirigir solicitudes al servicio correcto	`GET /api/users → User Service`
Autenticación	Validar tokens/credenciales antes de reenviar	Verificar JWT en cada request
Rate Limiting	Limitar solicitudes por cliente/IP	100 requests/minuto por API key
Transformación	Adaptar request/response entre cliente y servicio	Agregar campos, cambiar formato
Agregación	Combinar respuestas de múltiples servicios	Dashboard con datos de 3 servicios
Caché	Cachear respuestas frecuentes	Catálogo de productos por 5 min
Logging/Métricas	Registrar todas las solicitudes centralmente	Latencia, errores, throughput
CORS	Gestionar políticas de origen cruzado	Permitir dominios específicos

Flujo típico de una solicitud

1. Cliente envía: GET /api/products/123
2. Gateway recibe la solicitud
3. Gateway valida el token JWT → ✅ válido
4. Gateway verifica rate limit → ✅ dentro del límite
5. Gateway enruta a Product Service: GET /products/123
6. Product Service responde con datos del producto
7. Gateway transforma la respuesta (si es necesario)
8. Gateway registra métricas (latencia, status code)
9. Gateway devuelve respuesta al cliente

Patrones de composición

El API Gateway puede implementar diferentes estrategias de composición:

Request routing simple: Cada ruta del gateway mapea a un servicio específico.

/api/users/*     → User Service
/api/products/*  → Product Service
/api/orders/*    → Order Service

Agregación de respuestas: El gateway llama a múltiples servicios y combina las respuestas.

GET /api/dashboard
  → User Service: datos del usuario
  → Order Service: últimos pedidos
  → Product Service: recomendaciones
  ← Respuesta combinada al cliente

Ventajas

Desacoplamiento: Los clientes no conocen la topología interna de servicios
Cross-cutting concerns centralizados: Auth, rate limiting, logging se implementan una sola vez
Evolución independiente: Puedes reorganizar servicios internos sin afectar a los clientes
Simplificación del cliente: Una sola URL, un solo formato de autenticación
Observabilidad: Punto central para métricas, logs y trazas de todas las solicitudes
Seguridad: Los servicios internos no se exponen directamente a internet

Trade-offs / Desventajas

Punto único de fallo: Si el gateway cae, todo el sistema es inaccesible (requiere alta disponibilidad)
Latencia adicional: Cada solicitud tiene un salto extra de red
Complejidad operativa: El gateway necesita su propio despliegue, monitoreo y escalado
Cuello de botella: Todo el tráfico pasa por un solo componente (requiere escalado horizontal)
Riesgo de lógica de negocio: Es tentador agregar lógica de negocio en el gateway, lo cual es un anti-patrón
Acoplamiento al gateway: Cambiar de tecnología de gateway puede ser costoso

Cuándo usar

Arquitecturas de microservicios con múltiples clientes (web, mobile, IoT)
Cuando necesitas centralizar autenticación y autorización
Cuando los clientes necesitan datos agregados de múltiples servicios
Sistemas con requisitos de rate limiting y throttling
Cuando quieres ocultar la complejidad interna de los servicios a los consumidores externos

Cuándo evitar

Aplicaciones monolíticas donde no hay múltiples servicios backend
Sistemas internos donde los servicios se comunican directamente entre sí (service-to-service)
Prototipos o MVPs donde la complejidad adicional no se justifica
Cuando la latencia adicional de un salto extra es inaceptable

Tecnologías e implementaciones comunes

Categoría	Opciones
Cloud-managed	AWS API Gateway, Azure API Management, Google Cloud Endpoints
Open source	Kong, Traefik, APISIX, Tyk
Service mesh	Istio Gateway, Envoy
Frameworks	Spring Cloud Gateway (Java), Ocelot (.NET), Express Gateway (Node.js)

Relación con otros patrones

BFF (Backend for Frontend): Variante del API Gateway especializada por tipo de cliente
Circuit Breaker: El gateway puede implementar circuit breaking hacia los servicios downstream
Rate Limiting: Funcionalidad nativa del gateway para proteger los servicios
Service Discovery: El gateway necesita saber dónde están los servicios (Consul, Eureka, DNS)

Próximos pasos

El API Gateway es el punto de entrada de tu arquitectura. Para especializarlo por tipo de cliente, explora el patrón BFF (Backend for Frontend). Para proteger los servicios downstream de fallos en cascada, revisa el Circuit Breaker.