Una campaña que funciona, una mención en prensa, un vídeo viral o el lanzamiento de un producto pueden multiplicar el tráfico de tu web por diez en horas. Si tu infraestructura está dimensionada para el tráfico habitual, lo más probable es que se caiga justo cuando más visibilidad tienes.
Esta guía repasa cómo preparar el servidor para que aguante picos sin sustos: arquitectura, caching, balanceo, pruebas y monitorización.
Tabla de contenidos
Síntomas claros de servidor mal dimensionado
Antes de actuar, conviene reconocer las señales:
- Latencia alta (Time To First Byte > 1 segundo de forma sostenida).
- CPU o memoria al 80-100% en los momentos pico.
- Errores 5xx (500, 502, 503, 504) cuando el tráfico sube.
- Base de datos como cuello de botella: queries lentas, locks, max_connections agotadas.
- Caídas intermitentes sin patrón claro.
Si reconoces dos o más, el servidor no está listo para escalar.
Cinco pasos para aguantar tráfico alto
1. Hosting escalable o infraestructura en la nube
El primer cambio suele ser arquitectónico: pasar de un VPS estático a una infraestructura que escala automáticamente. Opciones reales:
- Auto Scaling Group en AWS (o equivalente en Azure/GCP) con plantillas de lanzamiento.
- Hosting gestionado escalable con capacidad provisionada bajo demanda.
- Servidores dedicados sobredimensionados si la carga es predecible y constante.
Sin elasticidad, sigues teniendo el mismo techo.
2. Balanceador de carga y arquitectura distribuida
Un load balancer (ALB en AWS, NLB, HAProxy, Nginx) reparte el tráfico entre múltiples instancias backend. Beneficios directos:
- Aguanta más conexiones simultáneas.
- Permite mantenimiento sin caída total (rolling deploys).
- Es la base para la alta disponibilidad real.
La regla práctica: con un solo servidor backend nunca tienes alta disponibilidad, da igual el tamaño que tenga.
3. CDN y caching agresivo
Cualquier contenido que pueda servirse desde caché alivia al servidor de origen:
- CDN delante (Cloudflare, CloudFront, Bunny) para estáticos: imágenes, CSS, JS.
- Caché de página completa (Varnish, Nginx FastCGI Cache, plugins WordPress como WP Rocket) para HTML.
- Caché de objeto (Redis, Memcached) para resultados de queries pesadas.
Una web bien cacheada puede aguantar 10x más tráfico con la misma infraestructura.
4. Optimización de backend, base de datos y código
Optimizar sin perfilar es ciego. Antes de tocar nada:
- Identifica queries lentas (slow query log de MySQL/PostgreSQL).
- Mide tiempos por endpoint (New Relic, Datadog APM, o un perfilador básico).
- Localiza el N+1 query si lo hay (clásico en ORMs).
Solo entonces tiene sentido añadir índices, refactorizar queries o cachear resultados. Tirar más CPU sin perfilar suele ser caro y no resolver.
5. Pruebas de carga y monitorización proactiva
Lanzar a producción sin haber probado el escenario de pico es jugar a ciegas. Herramientas:
- k6, Locust o JMeter para simular tráfico realista.
- CloudWatch / Datadog / Prometheus + Grafana para métricas en tiempo real.
- Alertas accionables (latencia p95 > 1s, error rate > 1%, CPU sostenida > 80%).
La monitorización detecta el problema antes de que el cliente o el cliente del cliente lo notifique.
Checklist resumen
Antes del próximo pico previsible, repasa:
- [ ] Capacidad elástica activa (auto scaling o equivalente).
- [ ] Balanceador de carga delante de al menos dos backends.
- [ ] CDN configurada para estáticos y caché HTML donde proceda.
- [ ] Slow query log revisado y queries críticas optimizadas.
- [ ] Pruebas de carga ejecutadas en staging que replican producción.
- [ ] Alertas configuradas en métricas clave (latencia, errores, saturación).
- [ ] Plan de respuesta documentado: quién, qué y cuándo si pasa algo.
Preguntas frecuentes
¿Cuánto tráfico debería poder aguantar mi servidor?
No hay un número universal: depende de tu pico real, no del tráfico medio. La regla práctica es dimensionar para el peor escenario previsible (campaña, lanzamiento, mención en prensa) con margen, y validarlo con pruebas de carga que repliquen producción. Si nunca has medido tu pico, ese es el primer paso.
¿Una CDN sustituye a tener buena infraestructura?
No, la complementa. Una CDN descarga estáticos y, con caché de página, mucho HTML, lo que puede multiplicar por diez el tráfico que aguantas con la misma infraestructura. Pero el contenido dinámico y las escrituras siguen golpeando tu origen, así que el backend y la base de datos tienen que estar igualmente dimensionados.
¿Es mejor escalar verticalmente (servidor más grande) o horizontalmente (más servidores)?
El escalado vertical es más simple pero tiene techo y no da alta disponibilidad: con un solo servidor, si cae, cae todo. El horizontal (balanceador + varias instancias) aguanta más, permite mantenimiento sin caída total y es la base de la alta disponibilidad real. Para picos serios, lo segundo.
¿Puedo prepararme para un pico con pocos días de aviso?
En parte. Activar CDN, caché agresiva y subir recursos se hace rápido. Lo que no se improvisa es rediseñar la arquitectura, optimizar queries lentas o validar con pruebas de carga. Por eso conviene dejar la infraestructura lista antes de necesitarla, no durante el pico.
¿Necesitas ayuda con la preparación?
En Elimática dimensionamos infraestructura para picos de tráfico previsibles e imprevistos: campañas, ecommerce en peak, lanzamientos. Auditamos lo que tienes y proponemos los cambios con impacto medible.