ADR-001: API Gateway, KrakenD frente a Kong
Aceptado el 10/11/2026 por Andrés.
Contexto
El PDF sugiere Kong como ejemplo ("no impuesta"). Se exige rate limit por partner y canal, con límites distintos por partner. Andrés conoce bien KrakenD y poco Kong.
Comparación (ediciones gratuitas)
| Capacidad | KrakenD comunitario | Kong código abierto |
|---|---|---|
| Validar tokens de Keycloak | Sí, con rotación automática de llaves | Sí, con el plugin JWT; el plugin OIDC completo es de pago |
| Límite por cliente | Sí, por claim propagado a cabecera | Sí, por consumidor |
| Límites distintos por partner | No: misma tasa para todos los clientes de un endpoint | Sí: el plugin se configura por consumidor |
| Contadores compartidos entre instancias | No: memoria por instancia (Redis es de la edición Enterprise) | Sí: políticas cluster o redis |
| Operación | Sin estado, configuración declarativa | Requiere base de datos o modo declarativo, más piezas |
| Continuidad de la edición gratuita | Activa | En duda: un competidor (Zuplo) afirma que desde la 3.10 no se publican imágenes de código abierto; sin confirmar en fuente oficial |
Decisión
KrakenD como gateway delgado. Las cuotas diferenciadas por partner las aplica Envoy en la malla (ADR-006).
Qué se sacrifica
- Las cuotas por partner viven un salto más adentro; hay dos lugares donde mirar límites.
- Se gana un gateway sin estado, que Andrés domina y puede defender, y coherente con no poner lógica en él.
Cuándo se revisaría
Si AndesRetail necesitara portal de desarrolladores, planes de consumo o monetización de APIs.
Fuentes verificadas el 10/11/2026
- Documentación de KrakenD: rate limit de router y rate limit con Redis (Enterprise).
- Documentación de Kong: plugin Rate Limiting (políticas local, cluster y redis).
- Página de Zuplo sobre Kong OSS (fuente interesada).