Más compras, menos ingreso por compra
Según el balance preliminar de la Cámara de Comercio de Santiago (CCS), el CyberMonday de este año sumó 5,3 millones de compras, un 20% más que en 2025 y la cifra más alta en 15 años. Las ventas llegaron a US$452 millones, solo 2% más en términos nominales, porque el ticket promedio cayó 15%. Son cifras preliminares y pueden cambiar.
Lo que vemos desde la arquitectura es una lectura nuestra, no un dato de la CCS: si cada peso vendido exige más operaciones, ya no basta saber cuánta capacidad tiene la plataforma. Importa cuánto cuesta atender cada compra. En las empresas medianas y grandes en Chile que venden online, esa cuenta rara vez está hecha, y menos aún el ensayo de qué ocurre si un servidor o una zona completa deja de responder en el día de mayor venta.
El método de Amazon: provocar la falla antes de que ocurra sola
Según el blog de AWS, Amazon ejecutó más de 44.000 experimentos de falla controlada con AWS Fault Injection Service (FIS) antes de Prime Day 2026, más de seis veces los de 2025. El artículo no detalla qué escenarios se probaron, y no hace falta: lo que una empresa chilena puede llevarse es el método, no la cifra.
● Hipótesis: antes de cada prueba se escribe qué debería pasar, por ejemplo, que si cae un servidor las compras sigan funcionando.
● Falla acotada: FIS permite provocar situaciones como latencia, caída de servidores o de una zona completa, con el alcance limitado de antemano.
● Medición: se observa qué hizo realmente la plataforma. La diferencia con la hipótesis es el trabajo pendiente.
Primero medir: el costo de cada compra en AWS
La cuenta es simple: la factura de nube del período dividida por las compras atendidas. Lo difícil es el numerador, porque sin una factura ordenada no se sabe qué parte corresponde a la tienda online y qué parte a otros sistemas. Con las cargas de la plataforma etiquetadas en AWS, la cuenta se puede obtener y seguir mes a mes.
Etiquetada la plataforma, también se puede separar lo que crece con cada compra de lo que permanece fijo, y ver si el costo por compra sube o baja cuando la demanda aumenta. Esa es la información que un gerente general necesita para conversar con su equipo de TI en términos de negocio y no solo de servidores.
Como partner oficial de AWS, abordamos esto como arquitectos de soluciones. Definimos con el equipo un esquema de etiquetado de costos, armamos un tablero FinOps que muestre el costo por transacción en el tiempo y revisamos el autoscaling (la capacidad que la plataforma agrega o retira sola según la demanda) y los cuellos de botella, es decir, los puntos donde el sistema se satura antes que el resto. Con esa lectura, cada empresa decide qué ajustar antes del peak y qué dejar como está. No prometemos ahorros de antemano: la medición indica dónde mirar.
Esquema conceptual de Pronodo: de la venta en el peak a la decisión de qué ajustar
Ensayar en calma: game days y pruebas de carga
Un ensayo en calma cuesta menos que descubrir el problema el día de mayor venta. Por eso recomendamos hacerlo por etapas y sobre la arquitectura que la empresa ya tiene, no sobre una réplica ideal.
● Game days con FIS: diseñamos jornadas de ensayo con hipótesis y límites de impacto definidos, y acompañamos al equipo mientras se provoca y se observa la falla.
● Pruebas de carga previas al peak: simulamos un volumen de compras cercano al esperado para ver dónde responde mal la plataforma y si el autoscaling reacciona a tiempo.
● Runbooks e infraestructura como código: documentamos paso a paso qué hacer ante cada falla y dejamos el entorno definido como código, para repetir los ensayos antes de cada peak sin partir de cero.
Los hallazgos de cada ensayo vuelven al tablero y a los runbooks: lo que se corrige queda documentado y lo que se acepta como riesgo queda explícito. Así, antes del peak la gerencia tiene claro qué se ajustó, qué se decidió dejar y qué conviene volver a ensayar.
Cada ensayo se confirma contra la arquitectura de cada empresa: no es lo mismo una tienda con un único punto de pago que una con varios servicios independientes, y los límites de impacto se fijan en consecuencia.
La recomendación de Pronodo
Como Socio Tecnológico especializado en infraestructura y FinOps sobre AWS, recomendamos tratar el próximo peak de fin de año como una fecha de prueba y no solo de venta. Proponemos partir por tres pasos de diagnóstico, cada uno con un entregable concreto:
- Medir el costo por transacción. Entregable: un tablero FinOps con la plataforma etiquetada en AWS y el costo por compra mes a mes.
- Revisar autoscaling y cuellos de botella. Entregable: un informe de revisión, apoyado en pruebas de carga, con los puntos de saturación y los ajustes priorizados antes del peak.
- Ensayar la falla. Entregable: un plan de game day con FIS, con hipótesis y límites de impacto, junto con los runbooks y la infraestructura como código para repetirlo.
No todas las empresas necesitan todo a la vez. Conviene partir por un diagnóstico técnico de la plataforma antes de cualquier inversión.