Agregar un CDN parece algo obvio. Hasta que es lo único que se interpone entre tú y un deployment roto.
El contexto
Estábamos en medio de dos cambios en paralelo: un rediseño completo del sitio web y una migración de servidores. Ambos estaban planeados, con scope definido, y avanzando sin problemas... hasta que notamos que un segmento de usuarios empezó a tener fallas después de la migración. No todos. No de forma consistente. Pero suficiente para ser un problema real.
El culpable: las cookies.
El problema
El servidor anterior había acumulado cookies con el tiempo. El nuevo servidor introdujo las suyas propias. Cuando un usuario llegaba en medio de la migración —todavía cargando las cookies antiguas y recibiendo las nuevas del sitio rediseñado— el payload combinado superaba el tamaño máximo aceptado por el balanceador de carga: 16 KB.
Este límite no es arbitrario. Es una restricción dura que aplican la mayoría de los balanceadores de carga y CDNs a nivel HTTP. Una vez que lo cruzas, las solicitudes empiezan a fallar silenciosamente o a ser rechazadas.
Para hacerlo más complejo: el dominio no estaba bajo nuestro control directo. Apuntaba al balanceador mediante un CNAME de un proveedor DNS externo. Eso significaba que no podíamos cambiar el ruteo sin coordinar con terceros, ni tocar la configuración del balanceador directamente.
Por qué era difícil
Lo complicado no era el fix técnico. Era la restricción principal: no podíamos permitirnos ninguna afectación al usuario durante el cambio.
El error too_many_redirects solo aparecía para usuarios con payloads de cookies grandes —sesiones específicas, navegadores específicos, rutas específicas entre el sistema viejo y el nuevo—. Un cutover total habría expuesto a todos al riesgo. Y hacer rollback tampoco era una opción limpia, porque la migración ya estaba parcialmente en vivo.
Necesitábamos una solución que:
- Interceptara las solicitudes antes de llegar al balanceador
- Limpiara las cookies basándose en una whitelist (conservando solo lo necesario)
- Solo modificara el request, sin disparar redirects
- Pudiera desplegarse sin tocar el registrador del dominio ni el balanceador
La solución
Introdujimos una capa de CDN entre el DNS y el balanceador, y cambiamos el CNAME para que apuntara al CDN en lugar de ir directamente al balanceador.
En el edge del CDN, adjuntamos una función Lambda@Edge que se ejecutaba en cada solicitud entrante. Su trabajo era simple: leer las cookies, aplicar la whitelist, eliminar todo lo demás, y reenviar el request limpio hacia abajo.
Sin redirects. Sin pérdida de sesión para las cookies en la whitelist. Sin cambios en el código de la aplicación ni en la configuración del balanceador.
La arquitectura final quedó así:
[DNS → Firewall] → CDN → (Lambda@Edge) → Balanceador → Cluster
El CDN nos dio la capa de ejecución en el edge que necesitábamos. La función Lambda@Edge nos dio control preciso a nivel de request. Y como solo modificábamos los headers del request —nunca la respuesta—, el loop de too_many_redirects nunca se disparó.
Lo que aprendimos
Entiende qué está bajo tu control y qué no. El dominio estaba fuera de nuestro registro. El balanceador tenía límites fijos. Las cookies existentes de los usuarios no eran negociables. Trabajar dentro de esas restricciones moldeó cada decisión.
El CDN no era el objetivo, era el habilitador. No lo agregamos por rendimiento ni caché. Lo agregamos porque nos daba una capa programable exactamente donde la necesitábamos: entre el usuario y el balanceador.
Whitelist es más seguro que blacklist. En lugar de intentar identificar cuáles cookies causaban el desbordamiento y eliminar solo esas, invertimos el enfoque: definir qué debe sobrevivir, eliminar todo lo demás. Más simple de mantener, más seguro de desplegar.
Los cambios sin downtime son decisiones de arquitectura, no trucos de deployment. La razón por la que pudimos hacer este cambio sin afectar a los usuarios no fue suerte: fue que la arquitectura nos permitió insertar una nueva capa sin modificar nada de lo que estaba debajo.
Conclusión
La buena arquitectura no siempre se trata del diseño más elegante. A veces se trata de entender cómo interactúan tus sistemas entre sí, identificar dónde tienes apalancamiento real, y elegir el recurso correcto según las restricciones que tienes hoy —no las que quisieras tener—.
Un CDN y una pequeña función Lambda resolvieron lo que parecía un problema de cookies. Pero lo que realmente resolvieron fue un problema de control.
Top comments (0)