"Necesitamos más servidores." Esa frase, dicha con urgencia a las 2 de la mañana mientras un servicio se cae por saturación, es el síntoma de un problema que debió resolverse semanas antes. Capacity planning no es reaccionar cuando la infraestructura colapsa. Es la disciplina de entender cuánta capacidad tienes, cuánta vas a necesitar, y tomar decisiones antes de que la demanda supere la oferta.
La mayoría de los equipos no hacen capacity planning. Aprovisionan por intuición, escalan por pánico y descubren los límites de su infraestructura cuando los usuarios ya los están sufriendo.
Capacity planning no es "agregar más servidores cuando va lento"
Escalar reactivamente es caro, lento y arriesgado. Cuando ya estás en un incidente de saturación, aprovisionar nuevos recursos toma tiempo: minutos si tienes autoscaling bien configurado, horas si necesitas aprobar presupuesto y levantar máquinas manualmente. Y durante ese tiempo, los usuarios están sufriendo degradación o caídas totales.
Capacity planning es un proceso continuo de tres fases: medir la capacidad actual, proyectar la demanda futura, y decidir cuándo y cómo escalar. Las tres requieren datos, no intuición.
Las métricas que importan (y por qué los promedios mienten)
Los cuatro recursos fundamentales son CPU, memoria, disco y red. Pero la forma en que los mides determina si tu capacity planning sirve o no.
El promedio de CPU al 45% parece saludable. Pero si el p95 está al 92% y el p99 toca el 100%, tienes un problema que el promedio oculta. Los percentiles altos revelan la realidad que los promedios esconden. Para capacity planning, siempre usa p95 y p99, nunca promedios.
- Throughput vs latencia: un servicio puede manejar 10,000 requests por segundo con latencia de 50ms. Cuando el throughput sube a 12,000, la latencia no sube linealmente: se dispara exponencialmente. Esta curva no lineal es lo que hace que la saturación sea tan peligrosa.
- Saturación como métrica predictiva: la saturación mide cuánto de un recurso está en uso relativo a su máximo. Es la métrica más importante para capacity planning porque te dice cuánto margen tienes antes del colapso. Un recurso al 80% de saturación no tiene un 20% de margen — tiene mucho menos, porque el rendimiento se degrada exponencialmente a partir del 70-80%.
Modelos de predicción: tres enfoques que funcionan
Predecir la demanda futura no requiere modelos de machine learning sofisticados. Requiere disciplina y datos históricos.
- Basado en tendencias (extrapolación lineal): toma los datos de consumo de los últimos 3-6 meses y proyecta la tendencia. Si tu uso de CPU crece un 5% mensual, en 4 meses estarás al 80% de saturación. Simple, efectivo, y suficiente para la mayoría de casos. La limitación: no captura cambios bruscos.
- Basado en eventos: lanzamientos de producto, campañas de marketing, temporadas pico (Black Friday, fin de año). Estos eventos generan picos que la extrapolación lineal no predice. Para cada evento conocido, estima el multiplicador de tráfico basado en eventos anteriores similares y aprovisiona con anticipación.
- Basado en pruebas de carga: no predices, simulas. Ejecuta pruebas de carga que repliquen el patrón de tráfico esperado y mide dónde se rompe la infraestructura. Es el método más preciso, pero requiere inversión en entornos de prueba representativos y herramientas como k6, Gatling o Locust.
En la práctica, los tres se complementan. Extrapolación para el baseline, eventos para los picos, y pruebas de carga para validar que tus proyecciones se sostienen bajo presión real.
Vertical vs horizontal: cuándo escalar en cada dirección
No toda la escala es igual, y elegir mal la dirección tiene consecuencias.
Escalar verticalmente (más CPU, más RAM, disco más rápido) es la primera opción por simplicidad. No requiere cambios en la arquitectura. Una base de datos que necesita más memoria para su working set se beneficia directamente de un upgrade vertical. Pero tiene techo: eventualmente llegas al límite del hardware disponible, y cada salto de instancia es desproporcionadamente más caro.
Escalar horizontalmente (más instancias detrás de un balanceador) escala mejor a largo plazo, pero requiere que tu aplicación lo soporte: estado distribuido o sin estado, distribución de carga, consistencia eventual en muchos casos. Si tu servicio fue diseñado como monolito con estado en memoria, escalar horizontalmente no es simplemente "agregar más nodos."
La regla práctica: vertical primero, horizontal cuando el vertical no alcanza. Pero diseña siempre pensando en que eventualmente necesitarás horizontal.
En la práctica: el proceso trimestral
Capacity planning no es un proyecto de una vez. Es un proceso recurrente. Así lo implemento:
- Revisión trimestral de tendencias: cada trimestre, revisa las métricas de saturación de todos los servicios críticos. Identifica cuáles se acercan al 70-80% y proyecta cuándo llegarán al límite.
- Alertas proactivas de saturación: configura alertas al 80% de saturación en CPU, memoria, disco y conexiones. No al 95% — a ese punto ya estás en degradación. El 80% te da margen para actuar.
- Documentar decisiones y supuestos: cada decisión de sizing debe quedar documentada: por qué elegiste esa instancia, qué crecimiento asumiste, cuándo debería revisarse. Sin este registro, en 6 meses nadie sabe por qué el servicio tiene el tamaño que tiene.
- Pre-provisionar para eventos conocidos: si sabes que viene un Black Friday, no esperes a la semana anterior. Aprovisiona con 2-3 semanas de anticipación y ejecuta pruebas de carga sobre la nueva capacidad.
El anti-patrón: sobre-aprovisionar por miedo
El extremo opuesto al bajo aprovisionamiento es igualmente problemático. He visto organizaciones que aprovisionan 10x la capacidad necesaria "por si acaso." El resultado: facturas de cloud de seis cifras mensuales con utilización promedio del 8%.
El sobre-aprovisionamiento nace del miedo, no de los datos. Es la versión infraestructura de "tiremos dinero al problema." No es capacity planning — es ausencia de planning con presupuesto infinito.
Capacity planning real busca el equilibrio: suficiente margen para absorber picos sin desperdiciar recursos en capacidad ociosa. Ese equilibrio requiere datos, no corazonadas.
El costo de no planificar
La falta de capacity planning no se manifiesta como un error en un log. Se manifiesta como latencia que sube gradualmente, como incidentes que ocurren siempre en las mismas horas pico, como equipos que viven apagando fuegos en lugar de construir funcionalidad.
Cada incidente de saturación que podría haberse previsto es tiempo de ingeniería desperdiciado, usuarios perdidos y confianza erosionada. Y a diferencia de un bug en el código, la saturación no se resuelve con un hotfix de 5 minutos.
Capacity planning es la diferencia entre escalar con control y escalar con pánico. Mide, proyecta, decide. Antes de que el sistema te obligue.
