Hot Sale 2025: cómo escalar tu infraestructura sin colapsar (ni quebrar el bill de la nube)
Hot Sale 2025 arranca el 17 de mayo y se extiende hasta el 23 de mayo. Para los e-commerce mexicanos es la primera prueba grande del año, antes de Buen Fin y diciembre. Si tu plataforma alguna vez se cayó en hora pico, ya sabes que escalar mal es tan costoso como no escalar: pierdes ventas, pierdes confianza y el equipo entra en modo apagar fuegos durante una semana.
En esta guía compartimos el checklist operativo que aplicamos con clientes mexicanos para llegar a Hot Sale con infraestructura que escale donde tiene que escalar y deje de escalar cuando ya no se necesita (ese es el detalle que muchos olvidan y que termina inflando la factura de AWS por 3 meses).
El error de marco más común
La mayoría de los equipos preparan Hot Sale pensando solo en "aguantar el pico". El marco completo tiene tres momentos:
- Antes: infraestructura lista, probada y monitoreada.
- Durante: operación en sala de guerra, decisiones rápidas, comunicación con cliente.
- Después: análisis post-mortem, ajustes para Buen Fin, control de costo.
Si ignoras "después", llegas a Buen Fin con la misma infraestructura inflada y vas a pagar de más todo el segundo semestre.
Antes del evento: las 6 acciones críticas esta semana
1. Pruebas de carga reales
No "el equipo cree que aguanta". Pruebas con herramientas como k6, Locust o Artillery, simulando 3x a 5x el pico del año pasado. Mide:
- Tiempo de respuesta de checkout completo.
- Throughput de la base de datos en escritura.
- Comportamiento del carrito en concurrencia.
- Pasarela de pago bajo estrés.
Si tu peak histórico fue de 800 órdenes por minuto, prueba 3,000. Mejor que reviente en staging que en producción.
2. Autoescalado configurado y probado
Tener autoescalado en AWS, GCP o Azure no es lo mismo que tenerlo bien configurado. Verifica:
- Métricas correctas: no solo CPU. Memoria, latencia P95, longitud de cola, conexiones activas.
- Tiempos de warm-up realistas. Si tu app tarda 90 segundos en arrancar, el autoescalado que reacciona a CPU al 80% llega tarde.
- Cap superior definido. Sin límite, una métrica mal interpretada puede prender 200 instancias en minutos.
- Pruebas de scale-down. Tu autoescalado debe regresar a baseline cuando el tráfico baje, no quedarse arriba.
3. Base de datos con réplicas de lectura
El cuello de botella más común no es el cómputo: es la base de datos. Configura al menos una réplica de lectura y manda a ella todo lo que no necesite la versión más reciente del dato (catálogo, búsqueda, reseñas, perfil de usuario).
Para escritura, considera:
- Aumentar instancia temporalmente (RDS o Cloud SQL permiten cambio en minutos).
- Optimizar índices que sí se usan en consultas calientes.
- Encolar operaciones no críticas (envío de emails, sincronización con ERP) para que no compitan con checkout.
4. CDN en assets y caché agresiva
Toda imagen, CSS, JavaScript y video debe servirse desde CloudFront, Cloudflare o equivalente. La carga del origen debe ser solo la página dinámica, no los recursos. Verifica:
- TTL configurado por tipo de asset.
- Headers cache-control correctos.
- Origin shield activado si tu CDN lo soporta.
- Caché HTML para páginas que sí lo permitan (PDP, listados de categoría).
Una buena estrategia de CDN puede absorber 80% del tráfico sin tocar tus servidores.
5. Cold start eliminado en serverless
Si parte de tu app vive en Lambda o Cloud Functions, el cold start mata la experiencia en hora pico. Soluciones:
- Provisioned concurrency en funciones críticas (checkout, búsqueda).
- Mantener funciones "calientes" con pings periódicos donde no aplique provisioned.
- Optimizar paquete (idealmente menos de 50 MB) para reducir tiempo de arranque.
6. Runbooks listos
Documenta paso a paso qué hacer si:
- La base de datos se satura.
- La pasarela de pago empieza a rechazar.
- El CDN devuelve errores 5xx.
- Un microservicio crítico se cae.
Quién toma decisión, quién ejecuta, qué se comunica al cliente, en qué plazo. No improvises a las 11 de la noche del 17 de mayo.
Durante el evento: sala de guerra
Dashboards en vivo
Un solo dashboard con: ventas por minuto, latencia P95, tasa de error, carrito abandonado, conversión de checkout. Todo el equipo viendo lo mismo, sin tener que pedir reportes.
Comunicación con cliente
Si algo se degrada, comunicarlo bien protege la marca. Un banner que diga "estamos experimentando alta demanda, tu pedido está siendo procesado" es mejor que una página en blanco. Tener el banner pre-armado y poder activarlo con un toggle es ideal.
Disciplina de cambios
Congela los despliegues desde 48 horas antes del Hot Sale. Solo hotfixes con aprobación de líder técnico. Un push mal pensado en hora pico es la receta más común para una caída.
Después del evento: el lado que casi nadie cuida
1. Apaga lo que ya no necesitas
El día 24 de mayo, revisa qué se prendió durante el evento y sigue prendido. Instancias adicionales, réplicas, provisioned concurrency, capacidades reservadas. Bajar lo que sobra evita facturas infladas durante meses.
2. Análisis post-mortem honesto
Reúne al equipo dentro de los 5 días siguientes. Sin culpas, con foco en sistema:
- ¿Qué funcionó bien?
- ¿Qué falló y por qué?
- ¿Qué métricas nos faltaron?
- ¿Qué runbook se quedó corto?
Documenta las acciones para Buen Fin (que llega en noviembre).
3. Análisis de costo
Compara el costo de la semana del Hot Sale con la semana anterior. Identifica:
- Qué línea de costo creció más de lo esperado.
- Qué optimización aplicaste tarde (deberías aplicarla antes en Buen Fin).
- Si tu alerta de presupuesto en AWS o GCP funcionó.
Cómo evitar el overspend
Tres mecanismos básicos que todo e-commerce debería tener activos:
- Presupuestos en AWS Budgets, Google Billing Budgets o Azure Cost Management con alertas a 50%, 80% y 100%.
- Anomaly detection activado en costos. AWS Cost Anomaly Detection y equivalentes detectan saltos atípicos en horas.
- Límites duros en servicios donde aplique (Lambda concurrency, Auto Scaling max).
Un cliente nuestro evitó una facturación de 14,000 USD adicionales en 2024 porque la alerta saltó al detectar que un endpoint sin caché estaba multiplicando llamadas a una función Lambda. Sin esa alerta, lo habrían detectado al cierre del mes.
Recomendación final
Hot Sale 2025 son siete días. La preparación bien hecha son tres semanas. Si arrancas hoy todavía estás a tiempo de hacer lo crítico: prueba de carga, autoescalado verificado, CDN agresivo, runbooks. Si lo dejas para la semana del 12, ya solo te alcanza para rezar.
En ALCA acompañamos a e-commerce mexicanos en preparación de temporada alta. ¿Quieres una revisión rápida de tu setup pre-Hot Sale? Te ayudamos esta semana. Conversemos 30 minutos sin costo.
