Patrón que proporciona un punto de entrada único para múltiples microservicios, manejando routing, autenticación, rate limiting y agregación de respuestas.
El patrón API Gateway proporciona un punto de entrada único para clientes que necesitan acceder a múltiples microservicios. En lugar de que el cliente conozca y llame directamente a cada servicio, el gateway actúa como un proxy inteligente que enruta, agrega, transforma y protege las requests.
Un API Gateway es fundamentalmente diferente de un simple load balancer o proxy reverso. Mientras estos últimos distribuyen tráfico, el gateway añade lógica de aplicación: autenticación centralizada, transformación de protocolos, agregación de respuestas de múltiples servicios, y aplicación de políticas de seguridad y rate limiting.
El patrón emerge naturalmente en arquitecturas de microservicios donde la complejidad de coordinar múltiples servicios desde el cliente se vuelve inmanejable. En lugar de que cada aplicación cliente implemente lógica de descubrimiento de servicios, manejo de errores, y autenticación para docenas de APIs, el gateway centraliza estas responsabilidades.
El gateway mantiene un registro de servicios disponibles y sus ubicaciones, enrutando requests basándose en paths, headers, o contenido del payload. Esto permite que los servicios backend cambien de ubicación sin afectar a los clientes.
Centraliza la verificación de identidad usando protocolos como OAuth/OIDC, validando tokens JWT, y aplicando políticas de autorización antes de reenviar requests a servicios internos.
Implementa límites de velocidad por cliente, API key, o endpoint para proteger servicios backend de sobrecarga. Los circuit breakers detectan servicios degradados y fallan rápidamente en lugar de propagar latencia.
Combina respuestas de múltiples servicios en una sola respuesta, reduce el número de round-trips desde el cliente, y transforma formatos de datos entre protocolos (REST a GraphQL, JSON a XML).
AWS API Gateway es un servicio completamente gestionado que se integra nativamente con Lambda y otros servicios AWS. Maneja automáticamente escalado, disponibilidad, y monitoreo.
# Ejemplo de configuración con AWS SAM
Resources:
ApiGateway:
Type: AWS::Serverless::Api
Properties:
StageName: prod
Auth:
DefaultAuthorizer: CognitoAuthorizer
Authorizers:
CognitoAuthorizer:
UserPoolArn: !GetAtt UserPool.Arn
MethodSettings:
- ResourcePath: "/*"
HttpMethod: "*"
ThrottlingBurstLimit: 200
ThrottlingRateLimit: 100Kong es un gateway open source construido sobre NGINX que ofrece plugins extensibles para autenticación, rate limiting, transformaciones, y observabilidad.
# Configuración Kong con rate limiting y circuit breaker
services:
- name: user-service
url: http://user-service:8080
plugins:
- name: rate-limiting
config:
minute: 100
hour: 1000
- name: proxy-cache
config:
response_code: [200, 301, 404]
request_method: [GET, HEAD]
cache_ttl: 300
routes:
- name: users-route
service: user-service
paths: ["/api/users"]NGINX Plus añade capacidades de API management a NGINX, incluyendo rate limiting dinámico, health checks activos, y dashboard de monitoreo.
# Configuración NGINX Plus con rate limiting
upstream user_service {
zone user_service 64k;
server user-service-1:8080 max_fails=3 fail_timeout=30s;
server user-service-2:8080 max_fails=3 fail_timeout=30s;
}
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
server {
listen 80;
location /api/users {
limit_req zone=api_limit burst=20 nodelay;
# Circuit breaker logic
error_page 502 503 504 = @fallback;
proxy_pass http://user_service;
proxy_set_header Authorization $http_authorization;
# Health check
health_check uri=/health match=server_ok;
}
location @fallback {
return 503 '{"error": "Service temporarily unavailable"}';
add_header Content-Type application/json;
}
}| Aspecto | API Gateway | Backend for Frontend |
|---|---|---|
| Propósito | Punto de entrada único para todos los clientes | Adaptador específico por tipo de cliente |
| Granularidad | Una instancia para toda la organización | Una instancia por aplicación frontend |
| Responsabilidad | Routing, autenticación, rate limiting | Agregación y transformación específica |
| Complejidad | Alta — debe servir múltiples casos de uso | Baja — optimizada para un cliente específico |
| Acoplamiento | Bajo con clientes, alto con servicios backend | Alto con cliente específico, bajo con otros |
| Escalabilidad | Cuello de botella potencial | Escala independientemente por cliente |
| Casos de uso | Microservicios compartidos, APIs públicas | Mobile vs web, diferentes versiones de UI |
En la práctica, muchas organizaciones combinan ambos patrones: un API Gateway para funcionalidades transversales (autenticación, rate limiting) y múltiples BFF para agregaciones específicas por cliente.
En arquitecturas modernas, el API Gateway se complementa con un service mesh como Istio o Linkerd. El gateway maneja tráfico norte-sur (cliente a servicios), mientras el service mesh maneja tráfico este-oeste (servicio a servicio).
# Istio Gateway + VirtualService
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: api-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: api-tls-secret
hosts:
- api.company.com
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: api-routes
spec:
hosts:
- api.company.com
gateways:
- api-gateway
http:
- match:
- uri:
prefix: /api/users
route:
- destination:
host: user-service
port:
number: 8080
fault:
delay:
percentage:
value: 0.1
fixedDelay: 5s
retries:
attempts: 3
perTryTimeout: 2sImplementa límites dinámicos basados en la salud del sistema backend, reduciendo automáticamente el tráfico cuando los servicios muestran signos de estrés.
Detecta fallos en servicios backend y sirve respuestas cacheadas o respuestas por defecto para mantener la disponibilidad del sistema.
Transforma automáticamente entre diferentes versiones de APIs, permitiendo evolución de servicios sin romper clientes existentes.
Gateway monolítico: Un gateway que contiene lógica de negocio específica de dominio. Esto viola la separación de responsabilidades y crea acoplamiento.
Agregación excesiva: Realizar joins complejos o lógica de negocio en el gateway. Esta lógica pertenece a servicios dedicados o BFF.
Single point of failure: No implementar alta disponibilidad en el gateway. Un gateway caído significa que toda la aplicación se vuelve inaccesible.
Transformación de datos pesada: Realizar transformaciones costosas en el gateway que deberían hacerse en servicios especializados o en el cliente.
Desde una perspectiva de ingeniería senior, el API Gateway resuelve el problema fundamental de la complejidad operacional en arquitecturas distribuidas. Sin él, cada equipo de frontend debe implementar descubrimiento de servicios, manejo de errores, autenticación, y agregación de datos — duplicando esfuerzo y creando inconsistencias.
El gateway centraliza políticas de seguridad y observabilidad, permitiendo que los equipos de plataforma implementen controles organizacionales sin modificar cada microservicio. Esto es crítico para cumplir con regulaciones como GDPR o PCI-DSS que requieren auditoría centralizada.
Sin embargo, introduce latencia adicional y se convierte en un punto de fallo crítico. La decisión de implementar un gateway debe balancear la simplicidad operacional contra el riesgo de crear un cuello de botella. En organizaciones con pocos servicios, la complejidad adicional puede no justificarse.
Estilo arquitectónico que estructura una aplicación como colección de servicios pequeños, independientes y desplegables, cada uno con su propia lógica de negocio y datos.
Servicio managed de AWS para crear, publicar y gestionar APIs REST, HTTP y WebSocket que actúan como puerta de entrada a funciones Lambda y otros servicios backend.
Patrón arquitectónico donde cada tipo de cliente tiene su propio backend dedicado que adapta las APIs de microservicios a las necesidades específicas de ese cliente.
Estándares de la industria para autorización delegada (OAuth 2.0) y autenticación federada (OpenID Connect), habilitando login con terceros y acceso seguro a APIs.
Capa de infraestructura dedicada a gestionar la comunicación entre microservicios, proporcionando observabilidad, seguridad y control de tráfico de forma transparente.
Modelo de computación en la nube donde el proveedor gestiona la infraestructura automáticamente, permitiendo ejecutar código sin aprovisionar ni administrar servidores, pagando solo por el uso real.
Estrategia de migración incremental que reemplaza gradualmente un sistema legacy con componentes nuevos, enrutando tráfico progresivamente hasta que el sistema antiguo se puede retirar.
Principios y prácticas para diseñar interfaces de programación claras, consistentes y evolucionables que faciliten la integración entre sistemas.