El peor fallo de escalabilidad no es tecnico. Es pagar la captacion, llevar trafico a la plataforma y descubrir que el sistema no puede absorber la demanda con margen. Cuando eso ocurre, el problema deja de ser una decision tecnica aislada y pasa a ser un problema de coste, riesgo operativo y capacidad de entrega.
Esta guia aterriza usar autoescalado, base de datos y cache con criterios que protejan conversion y coste con criterios que aguanten produccion, auditoria y crecimiento. El objetivo no es acumular tooling. Es recuperar control y reducir incertidumbre con un sistema que el equipo pueda gobernar sin dependencia innecesaria.
La capacidad fija convierte la variabilidad del negocio en coste estructural y aun así no garantiza nada
El sistema original seguía un patrón clásico y comprensible. Infraestructura fija dimensionada para el pico histórico. En muchas organizaciones esto nace de una intención razonable, que es reducir la probabilidad de caída. El problema es que, en producción, esa estrategia suele comprar tranquilidad aparente a cambio de dos costes silenciosos.
El primero es financiero. Pagas por capacidad infrautilizada casi todo el año. En este caso, el 95 por ciento del tiempo se pagaba infraestructura sin usar. Eso se convierte en coste base, el más difícil de recortar después, porque cualquier reducción se percibe como riesgo.
El segundo coste es operativo y suele ser peor. El pico histórico rara vez coincide con el pico futuro. Cuando una campaña rinde mejor de lo esperado o un medio grande enlaza el site, el dimensionamiento se queda corto y la plataforma entra en modo degradación. Empiezan las colas a crecer, sube la latencia, se dispara la contención en base de datos y aparecen errores. Lo más frustrante es que el equipo está “haciendo lo correcto” según el plan, pero el plan era el equivocado.
El porqué es importante. La capacidad fija convierte un problema variable como la demanda en un coste fijo y, aun así, no compra garantías frente a lo impredecible. Es el peor de ambos mundos. Si el negocio es variable, la plataforma necesita capacidad variable, pero esa elasticidad solo funciona si la gobiernas bien. Si no, cambias un incidente por otro. En vez de “no escala”, pasas a “escala tarde”, “escala en el sitio equivocado” o “escala y se come el margen”.
Esa distinción nos lleva directo a Kubernetes, pero no desde la moda. Desde el control.
El autoescalado en Kubernetes funciona cuando separas bien las capas y eliges señales que representen trabajo real
La nueva arquitectura se basó en Kubernetes con Cluster Autoscaler para añadir y eliminar nodos según demanda. A nivel conceptual hay dos escalados distintos que muchas organizaciones mezclan, y en incidentes reales se nota.
El escalado de pods con Horizontal Pod Autoscaler aumenta instancias de la aplicación. El escalado de nodos con Cluster Autoscaler añade capacidad de cómputo para que esos pods tengan dónde programarse. El orden importa porque si escalas pods sin capacidad subyacente, Kubernetes los deja en Pending. Desde fuera “parece” que estás escalando, pero en realidad estás acumulando deuda en la cola. En producción hemos visto casos donde todo estaba aparentemente en verde hasta que mirabas el scheduling y la verdad era simple. El cluster no podía crecer por límites de subnets, cuotas del proveedor o falta de tipos de instancia disponibles. Resultado, escalado fantasma y latencia real.
La parte que suele fallar no es activar el HPA. Es decidir con qué señales escalar.
Escalar por CPU y memoria puede servir como baseline, pero son proxies imperfectos del trabajo útil. Un servicio puede saturarse por latencia aguas abajo, como base de datos o un tercero, y mantener CPU moderada. Si en ese escenario escalas por CPU, no solo no ayudas. A menudo empeoras. Multiplicas conexiones, aumentas la presión sobre la base de datos y conviertes un cuello de botella en una cascada. En ecommerce eso suele manifestarse como “el sistema se pone nervioso” justo cuando más necesitas estabilidad.
Un patrón que funciona bien es escalar por señales que correlacionan con demanda no atendida. No son perfectas, pero son más cercanas a la realidad del negocio, que no es cuánta CPU consumes sino cuántas peticiones puedes servir dentro de SLO.
- Longitud de cola o tiempo de espera en cola cuando hay componentes asincrónicos o buffers claros
- Latencia P95 o P99 cuando has verificado que la causa es capacidad y no contención interna como locks o un query plan malo
- Tasa de errores por saturación tratada con cuidado porque no quieres escalar por 500 debidos a bugs, pero sí por señales específicas como timeouts hacia un recurso crítico
Si no haces esto, el autoscalado se vuelve reactivo tarde o directamente incorrecto. Y lo importante para un CTO es que el daño ocurre antes de que el escalado se ponga al día. El cliente no espera a tu control loop.
Esa decisión de señales nos llevó a otro punto que en la práctica decide si el autoescalado es una herramienta real o un adorno.
El tiempo de arranque define si el autoescalado llega a tiempo o solo llega a tus dashboards
Reducimos el tiempo de arranque de nuevos pods a menos de 30 segundos con imágenes ligeras y health checks agresivos. Esto suena como optimización, pero es diseño de sistema.
Si el pico crece 10x en 2 o 3 minutos y tus pods tardan 2 o 3 minutos en estar listos, el autoescalado llega cuando el cliente ya se fue. La documentación te dice que uses readiness y liveness. Lo que no te dice es que, en picos reales, el arranque falla por dependencias que no se ven en entornos de prueba. Migraciones bloqueantes, warmups excesivos, descarga de modelos, DNS lento, un secrets manager con rate limits, o incluso pulls de imagen lentos por saturación de red o por una política de seguridad que obliga a escanear en el runtime.
La regla práctica que aplicamos es que si tu negocio necesita absorber picos abruptos, tu time-to-serve de una réplica nueva debe ser bajo y, sobre todo, predecible. No necesitas un arranque heroico. Necesitas un arranque consistente. Por eso priorizamos imágenes pequeñas, builds reproducibles y checks que validan lo necesario para servir tráfico, no el estado ideal del proceso.
Una vez que el compute está bajo control, el cuello de botella se desplaza donde casi siempre termina, en los datos.
La base de datos es el activo crítico y el sitio donde el autoescalado suele romperse
La aplicación suele escalar razonablemente bien. La base de datos es donde se pagan los pecados arquitectónicos, y donde los picos te obligan a ser honesto con tu modelo de lectura y escritura.
Aquí usamos Aurora Serverless v2 para escalado automático de capacidad de cómputo, mientras que las réplicas de lectura se añaden dinámicamente durante picos. La lógica estratégica es sencilla. La mayoría de ecommerce tiene patrones de lectura intensiva, desde catálogo y PDP hasta búsquedas internas, recomendaciones e historial. Si separas lectura de escritura correctamente, capturas gran parte del pico sin convertir el writer en el cuello de botella.
Pero hay matices que importan en producción.
Aurora Serverless v2 escala compute. No arregla un esquema con locks, queries sin índices o transacciones largas. Si el cuello es contención, por ejemplo un UPDATE caliente en carrito o stock, aumentar capacidad puede mejorar throughput solo hasta cierto punto. Después suele fallar de forma más cara y más difícil de diagnosticar, porque el comportamiento del sistema varía con la capacidad. En equipos pequeños se tiende a usar Serverless como sustituto de tuning. Funciona hasta que deja de funcionar, y el día que no funciona el incidente se vuelve confuso porque el sistema “antes aguantaba”.
Las réplicas de lectura ayudan cuando el cuello es lectura. No ayudan cuando el cuello es escritura o cuando tienes lecturas que no toleran lag. En picos conviene clasificar endpoints por tolerancia al retraso. Qué puede ir a réplica aceptando segundos de retraso y qué tiene que ir al writer sí o sí. Esa clasificación no es un detalle técnico. Es una decisión de producto porque define la experiencia del usuario y el riesgo de inconsistencias visibles.
Aun con una base de datos bien dimensionada, el siguiente multiplicador de estabilidad suele ser la caché, pero solo si se gobierna con disciplina.
Redis ayuda cuando controlas consistencia, invalidación y stampedes, no cuando solo aumentas hit ratio
Aplicamos el patrón cache-aside con Redis para reducir la carga en la base de datos principal, con invalidación basada en eventos para mantener consistencia. En producción, cachear sin diseño suele acabar en dos tipos de problemas y ambos son caros. El primero es inconsistencia difícil de explicar al negocio, como precios desfasados o stock incorrecto. El segundo es un cache stampede, donde muchas instancias recalculan lo mismo tras expirar una key caliente y crean una tormenta contra la base de datos justo en el pico.
Lo que suele funcionar bien en ecommerce es combinar agresividad donde el negocio lo tolera con gobernanza donde el negocio no perdona.
- Cache agresiva para contenido de catálogo que cambia poco y que tolera segundos de propagación
- Invalidación basada en eventos para cambios importantes como precio, visibilidad o stock, evitando TTLs artificialmente cortos que generan recomputación constante
- Protección contra stampede con locks por key o mecanismos tipo single flight porque cuando expira una key caliente en pleno pico, el sistema puede autoinducirse el incidente
Si esta parte se hace mal, Kubernetes te da una falsa sensación de seguridad. La app escala, Redis escala, y la base de datos se convierte en la víctima del éxito. A nivel de ROI, eso se traduce en que pagas más por infraestructura durante el pico y aun así pierdes conversión por degradación.
Una vez estabilizado el origen, el siguiente salto de rentabilidad suele venir de evitar que el tráfico llegue al origen en primer lugar.
El CDN es elasticidad de alto ROI cuando las claves de caché reflejan la realidad del negocio
El CDN absorbió tráfico de assets estáticos y páginas cacheables, reduciendo la carga que llega a origen. Las reglas de caché se ajustaron basándose en patrones de acceso reales, buscando equilibrio entre frescura y reducción de carga.
Aquí el ROI suele ser inmediato. Cada request que no llega al origen es coste evitado y riesgo evitado. Además, el CDN reduce la variabilidad que ve tu backend, lo que estabiliza el autoscalado y mejora la predictibilidad de la plataforma durante campañas.
Lo que la documentación no te dice es que poner CDN no basta. Si no diseñas bien las claves de caché, puedes tener un hit ratio bajo aunque “tengas CDN”, o peor, servir contenido incorrecto a usuarios equivocados. En ecommerce el error típico es cachear sin aislar variaciones por moneda, país, idioma o sesión. La consecuencia no es solo técnica. Puede ser reputacional y, dependiendo del caso, legal.
Un patrón que suele funcionar es empezar conservador, medir hit ratio y carga en origen, y endurecer caché de forma incremental endpoint por endpoint. El objetivo es soberanía y gobernanza. Controlas qué se cachea, por cuánto tiempo y cómo invalidas, en lugar de depender de un switch global que no distingue entre contenido público y contenido sensible.
Todo esto se puede diseñar bien y aun así fallar por un motivo sencillo. No validaste los límites reales del sistema, solo validaste que los componentes “tienen autoscaling”.
Cómo validamos que el autoescalado existe en la práctica y no solo en el diagrama
Antes de dar por cerrado el diseño, validamos comportamiento bajo carga y límites operativos. Esta validación es donde se gana o se pierde la semana crítica, porque el fallo típico no es que el autoscaler no esté configurado. Es que algo impide que el escalado se materialice.
- Medimos el tiempo de reacción extremo a extremo desde que sube el tráfico hasta que hay capacidad real sirviendo requests, incluyendo provisión de nodos, pull de imágenes y readiness
- Revisamos límites y cuotas de forma explícita, incluyendo IPs disponibles en subnets, límites de instancias, límites de volúmenes, límites de Aurora en ACUs, límites de Redis y límites del proveedor de secretos
- Confirmamos que las señales de escalado representaban demanda no atendida y no solo consumo de CPU, y protegimos la base de datos con rate limiting y circuit breakers para evitar que un pico se convierta en cascada
- Ejecutamos pruebas de fallo parcial para ver qué pasa si una AZ se degrada, si hay throttling de APIs del cloud o si el CDN baja hit ratio por un cambio de caché
Si cualquiera de estos puntos falla, lo normal es que falle en el peor momento, cuando el negocio está monetizando el pico y la tolerancia a riesgo es mínima.
Con el control de escalado validado, el resultado se mide en dos dimensiones. La obvia, coste y rendimiento. La menos obvia, capacidad del equipo para operar sin vivir en modo guerra.
Menos coste base, menos riesgo en días críticos y menos carga cognitiva para el equipo
Durante el último Black Friday, la plataforma manejó un pico de 15x el tráfico normal sin degradación perceptible. El coste de infraestructura en días normales se redujo un 60 por ciento respecto al modelo anterior de capacidad fija. El equipo de operaciones pasó de vigilar dashboards con ansiedad a confiar en el sistema, interviniendo para optimizaciones en lugar de para supervivencia.
Para un CTO hay un impacto que no suele reflejarse bien en una hoja de cálculo pero tiene ROI real. Reducir carga cognitiva del equipo. Pasar de apagar incendios en eventos a operar un sistema que se adapta con gobernanza cambia el tipo de trabajo. Menos incidentes, menos war rooms, menos cambios reactivos en producción. Eso libera capacidad para mejorar conversión, performance real y roadmap. El retorno no es solo ahorrar en infraestructura. Es recuperar tiempo de ingeniería y reducir el riesgo operativo justo en los días que más facturan.
La idea central es simple, pero exige disciplina. La elasticidad no es un feature. Es un sistema de control. Kubernetes y autoscalers son herramientas. El valor llega cuando conectas métricas correctas, límites reales, comportamiento de base de datos y caché, y lo pruebas como si el negocio dependiera de ello. Porque depende.
Un gate previo al pico separa elasticidad real de elasticidad decorativa
El autoescalado no sirve de mucho si el sistema solo demuestra elasticidad en dashboards tranquilos. Antes de una campana fuerte, conviene pasar una validacion que compruebe si la plataforma absorbe carga con negocio, datos y quotas alineados.
| Control | Pregunta que debe responderse | Senal de no-go |
|---|---|---|
| Time-to-serve | Cuanto tarda una replica nueva en servir trafico util | Escalado mas lento que la entrada del pico |
| Base de datos | El writer, replicas y pools soportan la presion prevista | Locks, lag o conexiones agotadas |
| Cache y CDN | El hit rate se mantiene cuando cambia el patron de acceso | Stampede o caida brusca de cache hit |
| Quotas y capacidad | Subnets, instancias y servicios cloud tienen margen real | Limites invisibles que bloquean el cluster |
| Modo degradado | Las rutas de revenue sobreviven si el sistema se acerca al limite | No existe plan claro para proteger checkout |
Este gate cambia la economia del pico. Obliga a validar el sistema como una cadena, no como componentes aislados. Cuando falla, descubres antes donde invertir. Cuando pasa, el equipo deja de depender de heroics y el autoescalado por fin compra control, no solo esperanza.
Lecturas relacionadas que amplian esta decision
- Black Friday y picos de trafico: por que tantas plataformas siguen cayendo
- Kubernetes en produccion en 2026: practicas que reducen riesgo y coste
- Migracion cloud sin downtime: como mover cargas con control y rollback
- Nuestro servicio de infraestructura cloud y DevOps
Cuando merece actuar
Si esta decision ya esta afectando disponibilidad, coste o ventanas de cambio, el siguiente paso razonable es revisar arquitectura, limites y plan de operacion antes de anadir mas infraestructura.
