Viernes 09:00 horas: se abren las inscripciones para un congreso con 800 plazas. A las 9:03 a. m., el sitio muestra un error 503. A las 9:15 horas las redes sociales ya están tomando capturas de pantalla. El equipo de comunicaciones entra en pánico, el equipo técnico reinicia Apache "para ver" y nadie ha probado la página de pago bajo carga real.
Un sitio de eventos no es un blog que crece poco a poco. Se trata de una ventana de tráfico comprimido (a veces de solo unos minutos) que no podrás reproducir. Entonces, la pregunta correcta no es "¿qué anfitrión es el mejor?" ", pero ¿qué página debe encajar absolutamente, en qué momento y con qué plan B visible?
Planifica el gran día antes de elegir la oferta
Empiece por separar los flujos:
| Alimentación | Carga típica | Tolerancia a fallos |
|---|---|---|
| Páginas informativas (programa, ponentes) | Fuerte, especialmente en lectura | Promedio: una página alternativa estática es suficiente |
| Registro / emisión de entradas | Pico extremo, escribe DB | Zero: es el negocio principal |
| Área de participantes (credencial, PDF) | Moderado, después de la compra | Bajo |
| API de socio/escaneo de entrada | Varía | Baja el día del evento |
Luego, calcule el peor escenario creíble: ¿cuántas solicitudes simultáneas en la apertura? ¿Cuántas escrituras base por segundo? Una taquilla con cola virtual no tiene las mismas necesidades que un simple formulario integrado de Google Forms.
El tamaño útil comienza con el primer clic aterrador, no con el promedio mensual de Analytics.
Arquitectura: separando lo que debe aguantar de lo que puede esperar
Tres patrones que funcionan en el campo:
1. Páginas de presentación almacenadas en caché de forma agresiva + back office aislado. Programa, preguntas frecuentes, plan de acceso: servido de forma estática o mediante CDN con TTL largo. La emisión de tickets se ejecuta en un subdominio o en un servicio dedicado con un grupo de conexiones y sesiones de Redis.
2. Cola explícita. Es mejor mostrar "eres el número 847" con un sitio estable que un control giratorio infinito seguido de un 503. Soluciones como una página estática + token JWT o un servicio de cola dedicado evitan hacer estallar PHP-FPM de una vez.
3. Aumento temporal. En la nube (OVH Public Cloud, Scaleway, Hetzner Cloud), prepare una imagen o instantánea, un script de ampliación y, sobre todo, un regreso a la normalidad automatizado; de lo contrario, pagará por tres servidores hasta diciembre para un evento de junio.
Hosting: ¿compartido, VPS o nube elástica?
| Perfil del evento | Producto consistente | Por qué |
|---|---|---|
| Conferencia < 500 plazas, forma sencilla | VPS modesto + CDN | Control cron, PHP, Redis |
| Festival, venta de entradas de terceros (Eventbrite, Weezevent) | Compartido o estático | La carga crítica se subcontrata |
| Entradas internas, pico > 1000 solicitudes/s | Nube + balanceador de carga | Elasticidad y aislamiento DB |
| Transmisión en vivo integrada | Video CDN + origen separado | La transmisión de video no debe compartir PHP-FPM |
Shared falla con mayor frecuencia en tres límites: conexiones MySQL simultáneas, trabajadores PHP-FPM y falta de escalabilidad rápida. No se trata de una cuestión de “mala voluntad” por parte del anfitrión: es un modelo diseñado para suavizar el tráfico.
Observabilidad y runbook: el gran día no se puede improvisar
Dos semanas antes, establezca:
- Quién mira qué: CPU, latencia TTFB, errores 5xx, tamaño de archivo MySQL, conexiones Redis.
- Umbrales de alerta con números de móvil, no solo con correos electrónicos.
- Runbook escribe: “si 503 > 2 min → activar página estática / desactivar búsqueda / aumentar trabajadores”.
- Ventana de congelación de código: no se implementó el día anterior, a menos que se valide la revisión.
Pruebe restaurar una copia de seguridad básica: no "estamos haciendo copias de seguridad", sino "aquí es el momento de abrir la taquilla a las 8:55".
El pico: el pico es predecible, la ruptura no debería serlo
La promesa de “alojamiento ilimitado” no reemplaza la prueba de carga, la cola ni la página alternativa. El prestigio del centro de datos importa menos que el mapeo del primer cuarto de hora.
Decide y avanza sin puntos ciegos
- Identifique la página única que no debe caer (normalmente pago o validación de registro).
- Guardar en caché o estáticamente el resto al menos 72 horas antes de abrir.
- Prueba de carga esta página con un escenario realista (no una prueba abdominal en casa).
- Plan de documento B: página estática, mensaje de comunicación, extensión de apertura de ventas.
- Plan de descenso: reducción, facturación, archivo de registros.
Compare las ofertas elásticas en nuestro directorio y la comparación. Para el panel de caché, consulte Caché de página dinámica: decidir qué se puede almacenar en caché.
Preguntas frecuentes
¿Deberíamos sobredimensionar el servidor durante todo el año para el Día D?
No. Utilice caché, CDN, escalamiento temporal o arquitectura elástica para picos y luego revierta al costo normal.
¿Las redes compartidas son suficientes para un sitio de eventos?
Rara vez para emisión de entradas o apertura de registros concentrados. Un VPS, una nube elástica o una página estática + API separada es más realista.
¿Cuándo activar la CDN para un evento?
Tan pronto como las páginas de información estén estables, varias semanas antes. El gran día monitoreas, ya no configuras.
¿Qué probar antes de que se abran las ventas?
Prueba de carga en la página crítica, simulación de falla básica, procedimiento de cambio a una página estática documentada.
Un evento te deja con una sola toma. Dimensione durante ese cuarto de hora y duerma la noche anterior porque el runbook está escrito, no porque el servidor esté sobredimensionado durante todo el año.