Hot Sale 2024 (14-20 may): pre-flight para escalar tu infraestructura sin colapsar

Hot Sale 2024 arranca el martes 14 de mayo y cierra el lunes 20. La AMVO espera nuevamente cifras récord (en 2023 superó los 29.5 mil millones de pesos en ventas digitales). Si tu e-commerce participa, te quedan menos de dos semanas para preparar la infraestructura, y si ya viviste una temporada alta donde algo se cayó, sabes que escalar mal es tan caro como no escalar.

En ALCA hemos acompañado pre-flights de Hot Sale, Buen Fin y Black Friday a varios clientes mexicanos. La lista que sigue es lo que recomendamos accionar esta semana, organizada en tres bloques: antes (las próximas dos semanas), durante (los 7 días del evento) y después (la semana siguiente al cierre).

Antes: las 10 acciones que tienen que estar listas el 13 de mayo

1. Pruebas de carga reales contra producción (o mirror exacto)

La causa #1 de caídas es haber probado solo en staging con datos sintéticos pequeños. Recomendamos correr pruebas con k6 o Artillery simulando escenarios reales: pico de homepage, pico de búsqueda, pico de checkout simultáneo, abandono de carrito.

La meta no es "soportar el tráfico esperado" sino soportar 2x lo esperado durante 30 minutos sostenidos. Si revientan a 1.2x, llegas raspando.

2. Autoescalado verificado, no asumido

Tener autoscaling configurado no significa que funcione. Hay que disparar una prueba de carga y verificar que las nuevas instancias se levantan, se registran al balanceador y empiezan a recibir tráfico antes de que el p95 se degrade.

Tres errores típicos: warm-up muy lento del autoscaling group, health checks mal configurados que tumban instancias buenas, y límites de cuenta (vCPUs por región) que detienen el escalado a media subida. Pedir aumento de cuotas a AWS o GCP esta semana, no el 13 de mayo.

3. Base de datos con réplica de lectura y conexión revisada

RDS, Cloud SQL o Azure SQL en single-instance es Russian roulette en temporada alta. Recomendamos al menos una réplica de lectura activa, con la aplicación rooteando lecturas pesadas (catálogo, búsqueda, sesión) a la réplica.

Verificar también el pool de conexiones. PgBouncer o RDS Proxy salvan a más de un equipo de quedar sin conexiones disponibles cuando aparecen los primeros mil usuarios concurrentes.

4. CDN en assets, sin excepción

Imágenes, JS, CSS, fonts: todo detrás de CloudFront, Cloud CDN, Azure CDN o Cloudflare. La regla operativa: el origen no debería ver más del 5% del tráfico estático en pico. Si lo ve, hay configuración de cache mal puesta.

Revisar también que los headers Cache-Control estén bien definidos en assets versionados (cache largo) versus HTML dinámico (cache corto o nulo).

5. Eliminar o pre-warm cold starts

Lambdas y Cloud Functions con cold start de 2-5 segundos al primer hit son inaceptables en checkout. Provisioned Concurrency en AWS, Min Instances en Cloud Run o pre-warming periódico solucionan el problema.

Para microservicios en contenedores: revisar tiempos de boot. Si una imagen tarda 90 segundos en levantar, el autoscaling no te va a salvar a tiempo.

6. Sistema de pagos con redundancia

Si dependes de un solo proveedor (Conekta, Mercado Pago, Stripe) sin fallback, una caída te cuesta horas de ventas. Tener al menos un respaldo activo y lógica de retry probada con cliente real, no solo sandbox. Timeout máximo de 10 segundos.

7. Inventario sincronizado con locking adecuado

El bug clásico: dos compras simultáneas del último item. Sin optimistic locking o decremento atómico, vendes lo que no tienes, y la cancelación es peor que perder la venta.

8. Antifraude calibrado

Hot Sale es ventana de fraude masivo. Revisar reglas propias o servicio externo (Sift, Signifyd, Riskified). Calibrar para no rechazar compras legítimas pico.

9. Monitoreo y dashboards en vivo

Datadog, New Relic, Grafana, CloudWatch dashboards o equivalentes. Las métricas que tienen que ser visibles 24/7 durante el evento:

• Negocio: órdenes por minuto, ticket promedio, tasa de conversión, errores de checkout.
• Aplicación: p50/p95/p99 de latencia por endpoint, error rate, throughput.
• Infraestructura: CPU, memoria, conexiones a BD, espacio en disco, queue depth.
• Costo: spend acumulado del día (con presupuesto y alerta).

Si algo se va a 5 minutos del SLO, alguien tiene que recibir la alerta en menos de 60 segundos.

10. Runbook de incidentes y comunicación

Documentar de antemano: quién está de guardia cada turno, cómo se escala, cómo se comunica al cliente final si algo falla, cuáles son los tres tipos de incidente más probables y qué hacer en cada uno.

La comunicación al cliente importa tanto como la solución técnica: una página de status honesta y actualizada genera más paciencia que silencio.

Durante el evento: lo que sí (y lo que no) hay que hacer

Sí:

• Tener war-room virtual o presencial con técnicos de guardia las 24 horas críticas.
• Revisar dashboards cada 15 minutos las primeras 4 horas y luego cada hora.
• Documentar cualquier anomalía aunque se resuelva sola, para el post-mortem.

No:

• Hacer despliegues a producción durante el evento (excepto hotfixes verificados).
• Tocar configuraciones de autoscaling en caliente sin pensar dos veces.
• Asumir que "ya pasó el primer pico, ya estamos bien". Hot Sale tiene picos múltiples (apertura, almuerzo, después de cenar, último día).

Después: post-mortem y prep para Buen Fin

La semana siguiente al cierre es la más valiosa, y la mayoría de equipos la desperdician volviendo a backlog normal. Recomendamos:

• Post-mortem honesto: qué funcionó, qué falló, qué casi falla. Sin culpas, con datos.
• Cuantificar el costo: revisar el bill de la semana, identificar dónde se gastó más de lo planeado y por qué.
• Top 5 ajustes para Buen Fin: los Buen Fin de noviembre llegan en 6 meses; lo que no arregles ahora va a doler igual entonces.

Cómo evitar overspend

Una trampa común: en el afán de no caer, se sobreaprovisiona y el bill del mes se infla 60%. Para evitarlo:

• Presupuestos AWS Budgets / GCP Budget Alerts con alertas a 50%, 75%, 100% del esperado.
• Reservas o Savings Plans para el baseline. El pico se cubre con on-demand controlado.
• Spot instances para workers no críticos (procesamiento batch, cron jobs). Pueden recortar 60% a 80% del costo de cómputo asociado.
• Apagar ambientes no productivos durante los días del evento si están subutilizados.

El consejo más importante

La preparación de Hot Sale no es un proyecto técnico aislado. Es una conversación entre ingeniería, comercial, finanzas y atención a clientes. El equipo técnico no decide solo qué tan agresivo ser con el escalado: necesita saber el objetivo de ventas, el costo aceptable de pérdida por hora caída y cuándo conviene degradar funcionalidad antes de tirar todo abajo.

Si esa conversación no ha pasado a 13 días del evento, vale más empezarla esta semana que terminar el último ítem técnico.

---

¿Quieres una revisión rápida de tu setup pre-Hot Sale? Te ayudamos esta semana. Agenda una sesión de 60 minutos y revisamos tu arquitectura contra esta lista.