La infraestructura de un evento que ocurre una sola vez

01El punto de partida

Tres mil personas entrando en el mismo minuto, cuando se anunciaba la votación. No era una curva sino un salto, y una arquitectura dimensionada para el promedio se cae justo ahí.

02Con qué no se podía negociar

• Disponibilidad del 99,9%. El presupuesto no era la restricción.
• La fecha no se mueve: el pico ocurre una sola vez.
• Si algo cae, no hay tiempo de restaurar: tiene que seguir solo.
• Todo se apaga cuando termina el evento.

03La decisión

Nube administrada: ese nivel de disponibilidad se compra hecho y no había tiempo de construirlo. Contenedores detrás de un balanceador, con un firewall filtrando inyección SQL, cross-site scripting y ráfagas de peticiones. Redis delante de la base, porque en una votación casi todo es lectura, y una réplica en otra zona lista para reemplazar a la principal sin intervención. Las dos zonas en Irlanda, la de menor latencia para Europa. Todo como código, para levantarlo, ensayarlo y apagarlo sin depender de la memoria de nadie.

05Lo que no estaba en el plan

Los registros del servidor web iban al mismo volumen de red, porque era la única forma de sacarlos del contenedor, y ahí empezaron a fallar. Se movieron fuera. Quedó la regla: un volumen compartido lleva solo lo que se comparte.

06El resultado

El pico se sostuvo. A los treinta días se apagó todo, como estaba previsto: ninguna cuenta quedó con recursos encendidos que nadie se anima a tocar. Acá la nube administrada era la respuesta correcta; en otros casos, la misma pregunta da la contraria.