HU

Humano

← Blog

11 de marzo de 2026

Cuánto cuesta un bottleneck que nadie toca — cómo calcularlo

Un bottleneck en producción tiene 4 componentes de costo. La mayoría de los equipos solo ven uno. Aquí está el framework para calcular los cuatro.

costosdiagnósticodecisión

Un servicio de procesamiento de pagos lleva 14 meses con una zona que el equipo evita tocar. El componente funciona, pero consume el 55% del cómputo de un cluster de 12 instancias c5.2xlarge. Los deploys en esa zona requieren un rollout manual con feature flag y alguien de guardia. Nadie recuerda la última vez que se modificó sin un incidente.

El CTO sabe que es un problema. Pero cuando le preguntan cuánto cuesta, no tiene un número. Sin un número, no hay business case para invertir en resolverlo.

Este framework calcula ese número.

Los 4 componentes del costo

Un bottleneck en producción no solo cuesta infraestructura. Tiene cuatro componentes, y la mayoría de los equipos solo miden el primero.

1. Costo directo: la infraestructura compensatoria

Es lo más visible: el cómputo, memoria o almacenamiento que existe para compensar la ineficiencia del componente.

Cómo calcularlo:

Identificar qué fracción de la infraestructura del servicio se consume por el componente problemático. Si el servicio corre en 12 instancias c5.2xlarge (on-demand: ~$250/mes cada una = $3,000/mes, precio referencial a marzo 2026 en us-east-1) y el componente consume el 55% del CPU:

Costo directo = $3,000/mes × 0.55 = $1,650/mes = $19,800/año

Si el servicio usa reserved instances o savings plans, ajustar al costo efectivo. Si usa spot instances, el costo directo baja pero el costo de riesgo (componente 4) sube.

Dónde encontrar los datos:

2. Costo indirecto: el tiempo de ingeniería

El equipo gasta tiempo manteniendo el componente funcionando — tiempo que no se refleja en ninguna factura de cloud pero que tiene un costo real.

Cómo calcularlo:

Estimar horas semanales que el equipo dedica a:

ActividadHoras/semana típicas
Monitoreo extra del componente (alertas, dashboards, revisiones)1-3h
Deploys manuales con feature flags y rollout cuidadoso2-4h por deploy
Investigar incidentes o degradaciones causados por el componente2-6h
Workarounds en otros servicios para evitar la zona1-3h
Onboarding: explicar a ingenieros nuevos por qué no tocar1-2h/mes

Si el equipo dedica ~6 horas semanales al componente y el costo fully-loaded de un ingeniero senior es $180K/año ($90/hora):

Costo indirecto = 6h/semana × 48 semanas × $90/hora = $25,920/año

Dónde encontrar los datos:

3. Costo de oportunidad: el roadmap bloqueado

Esto es lo más difícil de cuantificar pero suele ser el componente más grande. Si el bottleneck bloquea o retrasa funcionalidad que tiene valor de negocio, el costo de oportunidad es el ingreso o ahorro que esa funcionalidad habría generado.

Cómo estimarlo:

Preguntar: "¿Qué features o mejoras están bloqueadas o retrasadas porque requieren tocar este componente?"

Si hay una feature de facturación en tiempo real que lleva 4 meses retrasada porque requiere modificar el servicio de pagos, y esa feature reduciría churn en un 2% sobre una base de $500K MRR:

Costo de oportunidad = $500K × 0.02 × (4 meses / 12) = $3,333/mes de retraso

Si no hay features bloqueadas directamente, el costo de oportunidad puede ser más sutil: velocidad de desarrollo reducida en el área, evitando mejoras que tocan la zona, o sobre-engineering en servicios adyacentes para evitar el componente.

No todos los bottlenecks tienen un costo de oportunidad significativo. Un servicio batch que solo procesa reportes nocturnos puede tener alto costo directo pero bajo costo de oportunidad. Un servicio en el critical path de checkout casi siempre lo tiene.

4. Costo de riesgo: el incidente que todavía no pasó

El componente que nadie quiere tocar es el que falla de la peor manera cuando falla. El costo de riesgo es la probabilidad de un incidente grave multiplicada por su impacto.

Cómo estimarlo:

Costo de riesgo = P(incidente/año) × impacto por incidente

Si el componente tuvo 3 incidentes en los últimos 12 meses con un downtime promedio de 45 minutos, y el servicio procesa $200K/hora en transacciones:

Costo de riesgo = 3 × (45/60) × $200K = $450K/año en exposure

No todos los incidentes son downtime total. Incluir degradaciones parciales: si el p99 se duplica durante 2 horas y eso causa un 5% de abandono en checkout, el impacto es $200K/hora × 0.05 × 2h = $20K por evento.

Dónde encontrar los datos:

Sumando los 4 componentes

Para el ejemplo del servicio de pagos:

ComponenteCálculoCosto anual
Directo (infraestructura)55% de un cluster de $3K/mes$19,800
Indirecto (ingeniería)6h/semana a $90/hora$25,920
Oportunidad (roadmap)Feature retrasada 4 meses$13,332
Riesgo (incidentes)3 incidentes/año × $150K exposure$450,000
Costo total del bottleneck = $509,052/año

El costo directo de infraestructura — el único que el equipo veía — era menos del 4% del costo total. El 88% estaba en riesgo de incidentes.

Cómo usar este número

El número tiene dos usos inmediatos:

1. Justificar la inversión: Si el bottleneck cuesta $509K/año y una revisión diagnóstica cuesta $3,500, el costo de la revisión es el 0.7% del costo anual del problema. Incluso si la intervención posterior cuesta $20K, el ROI es claro — siempre que la intervención reduzca el costo al menos un 5%.

2. Priorizar contra otros problemas: Si otro bottleneck cuesta $80K/año y este cuesta $509K/año, la prioridad es obvia. Sin el cálculo, ambos se ven como "problemas técnicos que deberíamos resolver algún día."

Cuándo el costo no justifica intervenir

No todo bottleneck merece atención:

La decisión correcta a veces es no hacer nada — pero tiene que ser una decisión explícita con un número detrás, no una postergación por falta de datos.

Si quieres calcular el costo real de un bottleneck en tu sistema y necesitas un diagnóstico que identifique dónde se concentra el impacto, podemos empezar con una conversación de 15 minutos sin costo. Si no hay caso, te lo decimos.

Referencias