En un día normal todo va razonablemente bien: la web responde ágil, las APIs no se quejan y las gráficas de monitorización se mueven en rangos cómodos.
Hasta que llega una newsletter importante, una campaña de pago empieza a funcionar mejor de lo previsto o arranca la Black Week (BlackFriday y Cibermonday). De repente, el tráfico se dispara y se ve rápido si tu infraestructura está bien pensada o si cualquier pico se convierte en una guardia de madrugada.
Para muchos proyectos (eCommerce, SaaS, banca online, medios, gaming, etc.), los picos de tráfico no son una anomalía, sino parte del negocio. Y cuando hablamos de entornos de misión crítica, con alta disponibilidad geográfica y almacenamiento en red con replicación síncrona, el margen de error es muy pequeño.
Desde Stackscale, donde trabajamos a diario con cloud privado con Proxmox o VMware, servidores bare-metal y soluciones de almacenamiento en red para este tipo de escenarios, la conclusión es bastante clara:
no se trata solo de “poner más máquinas”, sino de diseñar la arquitectura para que esos picos formen parte del plan.
1. Antes de nada: entender de verdad tus patrones de tráfico
Sin datos, todo lo demás es intuición. El primer paso es tener una foto clara de cómo se comporta tu plataforma.
Preguntas que deberías poder contestar sin sudar:
- ¿Cuál es tu tráfico “normal” por hora y por día de la semana?
- ¿Cuáles han sido tus picos reales de los últimos 6–12 meses y qué los disparó?
- ¿Qué partes de la plataforma sufren primero cuando hay estrés?
- Checkout, login, APIs, búsquedas internas, área privada, etc.
- ¿En qué punto empiezan a aparecer errores, tiempos de respuesta altos o caídas de conversión?
Para esto, lo mínimo razonable es combinar:
- Métricas de aplicación: tiempos de respuesta por endpoint, proporción de errores, colas de trabajo.
- Métricas de infraestructura: CPU, RAM, I/O de disco, latencias de red, consumo de almacenamiento.
- Datos de negocio: carritos abandonados, formularios que no se completan, tickets de soporte durante campañas.
Con esa base puedes empezar a hablar de capacidad con sentido: “queremos soportar 3x el pico de noviembre pasado” es muy distinto a “necesitamos algo más potente porque la web va justa”.
2. Optimizar antes de escalar: los cuellos de botella habituales
Lo más habitual cuando una web se cae en un pico de tráfico es culpar al hosting. Y a veces es cierto… pero muchas veces no.
En la práctica, solemos ver una combinación de:
Frontend pesado
- Imágenes gigantes sin comprimir o sin formatos modernos.
- Demasiados scripts de terceros: tags, píxeles, chats, A/B testing, etc.
- Temas o frontends muy cargados de JavaScript que bloquean el renderizado.
Cuanto más “cara” es cada visita en términos de recursos, antes se satura la infraestructura, por muy buenos que sean tus servidores bare-metal o tu cloud privado.
Backend sin respiración
- Consultas a base de datos sin índices, o con lógica demasiado compleja.
- Abuso de plugins, módulos o extensiones que añaden lógica en cada petición.
- Falta de caché (de página, de fragmentos o de objetos) que obligue a recalcular todo en cada request.
- Tareas que deberían ir a una cola (envío masivo de emails, generación de informes, integraciones externas) ejecutándose en tiempo real.
Infraestructura al límite
Incluso con buen código, hay límites físicos:
- CPU y RAM permanentemente altos en las horas de más uso.
- Cabinas o sistemas de almacenamiento saturados de IOPS.
- Máquinas virtuales sobredimensionadas en servicios secundarios y subdimensionadas en la parte crítica.
Regla práctica:
antes de subir recursos en Stackscale (o donde sea), es muy recomendable:
- Limpiar frontend y medios.
- Revisar base de datos y caché.
- Quitar complejidad innecesaria en el backend.
Cada mejora en esta capa hace que el mismo hardware aguante más tráfico y que cada euro invertido en infraestructura rinda mejor.
3. De servidor único a arquitectura preparada para picos
Muchos proyectos empiezan en un único servidor (físico o virtual) que hace de “navaja suiza”: web, base de datos, caché, cron, colas… todo junto.
Funciona, hasta que deja de hacerlo.
En cuanto el negocio depende de esa plataforma o crece el tráfico, la prioridad pasa a ser:
- Reducir puntos únicos de fallo.
- Separar responsabilidades.
- Poder añadir capacidad sin tirar nada abajo.
Arquitecturas típicas que vemos en entornos críticos
Un patrón bastante frecuente en despliegues sobre cloud privado o bare-metal:
- Varios nodos de aplicación detrás de uno o más balanceadores de carga.
- Base de datos separada, con opción de réplicas de lectura cuando el volumen lo exige.
- Capa de caché/almacenamiento intermedio (por ejemplo, Redis, Varnish cache, proxies de caché, etc.).
- Almacenamiento en red centralizado, redundado, para simplificar la alta disponibilidad.
En Stackscale, muchos clientes optan por este tipo de arquitectura desde el principio o la van alcanzando por fases, especialmente cuando:
- No se pueden permitir ventanas de caída prolongadas.
- El crecimiento del tráfico ya es estructural, no puntual.
- Hay requisitos de cumplimiento, auditoría o SLA internos exigentes.
4. Alta disponibilidad geográfica y replicación síncrona: pensando en serio en el “plan B”
Cuando hablamos de misión crítica, no basta con que un nodo sustituya a otro dentro del mismo centro de datos. También hay que pensar en:
- Fallos de CPD completo.
- Problemas de red a nivel de operador.
- Incidencias graves a nivel de región/ciudad.
Aquí entran conceptos como:
- Georedundancia: tener recursos listos en un centro de datos secundario que pueda asumir cargas si el principal falla.
- Replicación síncrona de almacenamiento entre CPDs: las escrituras se confirman solo cuando se han almacenado en ambos lados, minimizando el riesgo de pérdida de datos en caso de caída.
Este tipo de arquitectura tiene sentido cuando:
- El RPO aceptable es prácticamente 0 (no puedes perder transacciones).
- El RTO esperado es muy bajo (recovery en minutos).
- El impacto de una caída prolongada supera con creces el coste adicional de la georedundancia.
En este contexto, un proveedor como Stackscale aporta:
- Centros de datos interconectados de forma redundante.
- Soluciones de almacenamiento en red diseñadas para replicación síncrona.
- Equipos técnicos acostumbrados a dimensionar y operar este tipo de entornos.
5. Plan de capacidad: margen suficiente sin pagar “sobre-ingeniería” todo el año
La pregunta práctica es: ¿cuánto margen necesito realmente?
Ni infra sobredimensionada permanentemente, ni ir siempre “en rojo”:
- Parte de picos reales, no de sensaciones.
- Trae a la mesa las gráficas reales de tus días más fuertes.
- Define un objetivo razonable:
- Por ejemplo, soportar 3x tu pico actual con tiempos de respuesta aceptables.
- Traduce eso a infraestructura:
- ¿Cuántos nodos de aplicación?
- ¿Qué tamaño y tipo de servidores bare-metal o recursos de cloud privado?
- ¿Qué rendimiento mínimo necesitas en el almacenamiento en red?
- Diseña escalones de crecimiento con tu proveedor:
- Subir CPU/RAM de las VMs sin parar el servicio.
- Añadir nodos al clúster de aplicación.
- Aumentar capacidad y rendimiento del almacenamiento en red y de la red entre CPDs.
La ventaja del cloud privado alojado frente al on-premise aquí es clara: puedes crecer por pasos, con costes más predecibles y sin tener que sobredimensionar hardware propio “por si acaso”.
6. Ensayo general: probar el límite antes de la próxima campaña
No quieres descubrir tus límites el día de tu mayor campaña del año. Lo razonable es hacer un ensayo general con antelación.
Elementos mínimos del test:
- Pruebas de carga a rutas críticas (inicio, buscador, listados, fichas, login, checkout, APIs).
- Monitorización fina durante las pruebas:
- Tiempos de respuesta.
- Uso de CPU/RAM.
- Latencia y saturación de I/O.
- Errores de aplicación.
- Simulación de fallos:
- Quitar un nodo de aplicación del balanceo y ver cómo responde el sistema.
- Probar cómo se comporta la plataforma ante un fallo parcial de almacenamiento o red (cuando el entorno lo permite, siempre en coordinación con el equipo de infraestructura).
El resultado debería ser una lista concreta de:
- Parámetros de configuración a ajustar.
- Recursos que ampliar (o reequilibrar).
- Procedimientos internos para el día de la campaña (qué mirar, cada cuánto, quién decide qué).
7. Picos “buenos” vs picos “malos”: campañas frente a DDoS
No todo pico de tráfico es una buena noticia. A las campañas exitosas se suman:
- Ataques DDoS a nivel de red o de capa 7 (HTTP).
- Bots que rastrean o atacan formularios.
- Tráfico automatizado que intenta explotar vulnerabilidades.
Para no mezclarlo todo, necesitas:
- Visibilidad: poder distinguir comportamientos anómalos por patrones de IP, user-agent, país, ruta, etc.
- Medidas de mitigación:
- WAF con reglas específicas.
- Rate limiting en endpoints sensibles.
- Protección DDoS aguas arriba y/o uso de CDN allí donde tenga sentido.
- Procedimientos de respuesta:
- Qué hacer si el tráfico se dispara de repente y no corresponde a una campaña planificada.
- Cómo coordinarse con el proveedor de infraestructura para filtrar en red antes de que el ataque llegue a los nodos.
Una buena arquitectura ayuda, pero la capa de seguridad y los procedimientos son igual de importantes para que los picos buenos sumen y los malos no tiren nada abajo.
Conclusión
Los picos de tráfico no van a desaparecer; al contrario, cada vez son más frecuentes y bruscos.
La diferencia está en si tu infraestructura:
- Los sufre como un problema imprevisible, o
- Los absorbe como algo previsto en el diseño.
Con cloud privado, servidores bare-metal, almacenamiento en red y replicación síncrona entre centros de datos, y una arquitectura pensada para alta disponibilidad geográfica, puedes pasar de “aguantar como se pueda” a planificar el crecimiento con cabeza.
Si estás revisando tu plataforma de misión crítica o preparando tu próxima gran campaña, es buen momento para sentarse con el equipo de Stackscale, revisar datos reales y definir juntos qué necesitas para que el próximo pico de tráfico sea una buena noticia, y no el inicio de una incidencia.
FAQ sobre picos de tráfico y arquitectura de infraestructura
1. ¿Qué diferencia hay entre escalar vertical y horizontalmente para gestionar picos de tráfico?
Escalar verticalmente significa dar más recursos a una misma máquina (más CPU, RAM, etc.). Es sencillo y funciona bien hasta cierto punto, pero tiene límite físico y sigue siendo un único punto de fallo.
Escalar horizontalmente implica repartir la carga entre varios nodos de aplicación detrás de uno o varios balanceadores. Es más trabajo de arquitectura, pero ofrece mejor resiliencia y más margen para crecer, especialmente en entornos de misión crítica y alta disponibilidad.
2. ¿Qué papel juega un proveedor de cloud privado como Stackscale frente a una solución on-premise?
En on-premise tú te encargas de todo: compra de hardware, instalación, mantenimiento, repuestos, crecimiento, etc.
Con un cloud privado alojado y servidores bare-metal en Stackscale, delegas la parte física y de centro de datos (energía, red, hardware, reemplazos, etc.) y te centras en la capa de sistema y aplicación. Además, dispones de opciones de georedundancia entre CPDs y almacenamiento en red preparado para replicación síncrona, algo más complejo de conseguir de forma eficiente en un único CPD on-premise.
3. ¿Cómo sé si necesito georedundancia y replicación síncrona o con un solo centro de datos me basta?
Depende de tu RPO/RTO y del coste real de una caída. Si tu negocio puede asumir perder algunos minutos de datos y estar fuera de servicio un rato mientras se recupera el CPD principal, quizá una buena alta disponibilidad interna sea suficiente.
Si, en cambio, cada minuto de caída implica un impacto serio (económico, regulatorio o de reputación) y no puedes permitirte perder transacciones, lo habitual es plantear dos centros de datos y algún tipo de replicación (síncrona o asíncrona, según el caso). La recomendación final sale del cruce entre riesgo y coste.
4. ¿Cada cuánto tiempo debería repetir pruebas de carga en mi plataforma?
Lo razonable es hacerlas al menos:
- Antes de grandes campañas previsibles (Single Day, Black Friday, Cibermonday, Black Week, lanzamientos importantes, etc.).
- Después de cambios relevantes en la arquitectura (nueva versión de la aplicación, cambio de base de datos, nuevo proveedor, etc.).
En proyectos muy dinámicos, hay empresas que las integran en su ciclo de CI/CD de forma periódica (por ejemplo, mensual o trimestral). La idea es que los cambios en la aplicación y en la infraestructura no se acumulen durante años sin volver a comprobar cómo responde el sistema bajo estrés.
