Blast Radius

Qué es

Blast Radius es el alcance real o potencial del impacto que puede producir un fallo o cambio. Responde: si esta cosa falla, ¿qué parte del sistema, tráfico, usuarios o negocio puede verse afectada, de qué manera y durante cuánto tiempo? Es una descripción del impacto bajo un escenario, no una propiedad única e inmutable de un componente.

Una dependencia compartida puede tener alcance potencial global y producir un incidente pequeño si falla una operación usada por pocos usuarios. Un cambio aplicado a toda la flota puede comprometer mucho más que el host donde se detectó primero. Evaluar blast radius exige conectar componentes con funciones y población expuesta.

single dependency failure
 
Architecture A -> shared resource -> all customers exposed
Architecture B -> isolated cell -> one tenant subset exposed

Las etiquetas arquitectónicas no bastan: una DB, router o configuración común puede atravesar la separación aparente y ampliar el impacto.

Dimensiones del alcance

Dimensión	Pregunta
Usuarios y tenants	¿Qué población pierde servicio o corrección?
Requests	¿Qué proporción y clases de operaciones resultan afectadas?
Services	¿Qué componentes dejan de cumplir su contrato?
Cells y regiones	¿Dónde alcanza el fallo o cambio?
Datos	¿Qué conjuntos pueden quedar inaccesibles, inconsistentes o dañados?
Funcionalidad	¿Se pierde una función opcional o un flujo crítico completo?
Tiempo	¿Cuánto dura el impacto y qué efectos persisten después?

Un radio pequeño por usuarios no implica baja gravedad: un único tenant puede concentrar una parte importante del negocio. Un número de errores tampoco distingue rechazos explícitos de efectos duplicados o corrupción. Conviene describir alcance y tipo de impacto juntos, con un denominador y período identificables.

No reducir todo a una cifra sin contexto. «Afectó el 10 %» puede referirse a requests de un minuto, tenants o regiones; esas unidades no son intercambiables. Una función no disponible y una operación aceptada con resultado incorrecto representan daños distintos aunque sus poblaciones coincidan.

Potencial, exposición e impacto observado

El alcance potencial representa lo que el escenario puede alcanzar a través de dependencias y mecanismos de recuperación. La exposición describe dónde se aplicó el cambio o qué población usa el componente. El impacto observado describe lo que efectivamente ocurrió durante el incidente.

Una versión defectuosa desplegada en una cell expone inicialmente su población, pero todavía puede alterar datos compartidos o provocar failover hacia otras cells. Asimismo, no todos los expuestos ejecutan la ruta defectuosa. Mantener estas distinciones evita afirmar que una frontera de despliegue garantiza idéntica frontera de daño.

El scope puede crecer con el tiempo: una falla local se propaga, aumenta backlog y afecta posteriormente entregas o reconciliación. La recuperación del endpoint no demuestra que terminó el impacto de datos o de negocio. cascading-failures explica caminos de propagación; metastable-failures puede prolongar la condición degradada.

Probabilidad y Failure Domain

Blast Radius no equivale a probabilidad de fallo. Un componente muy confiable puede tener alcance enorme si es una dependencia global. Reducir la frecuencia esperada no reduce automáticamente la población afectable. Del mismo modo, particionar el impacto puede aumentar la cantidad de componentes sin implicar mayor indisponibilidad agregada por sí sola.

Blast Radius no equivale a Failure Domain. Un failure domain describe una frontera dentro de la cual ciertos fallos pueden compartir causas o recursos, o para la cual se diseña contención. Blast radius describe cuánto impacto real o potencial produce un escenario. Una falla puede atravesar dominios mediante dependencias, datos o recuperación.

Una región es una frontera física y operativa relevante para ciertos eventos; no garantiza aislamiento de un error de software que se distribuye a todas las regiones. Un tenant puede ser una frontera lógica de cuota y compartir el mismo storage. La independencia depende del tipo de fallo considerado.

Aislamiento y recursos comunes

bulkhead puede reservar workers, conexiones o capacidad por grupo. Esa partición limita determinados caminos de agotamiento; no separa automáticamente proceso, memoria, disco y datos. El análisis debe seguir recursos y contratos que permanecen compartidos.

AWS Well-Architected propone unidades aisladas y señala como riesgos el estado compartido, las interacciones entre cells y desplegar cambios simultáneamente en todas ellas. El alcance se reduce mediante aislamiento efectivo, no simplemente multiplicando nombres de instancias. Use bulkhead architectures to limit scope of impact.

circuit-breaker puede evitar nuevas invocaciones hacia una dependencia no saludable. Si su scope agrupa destinos o operaciones sanas con las fallidas, su apertura amplía la indisponibilidad observable. load-shedding puede preservar funciones críticas, pero también define explícitamente qué población o trabajo sacrifica.

Ninguno elimina todos los caminos de propagación. Fallbacks y failover pueden introducir dependencias nuevas durante un fallo. AWS documenta cómo una alternativa de recuperación llegó a ampliar el alcance de una interrupción al trasladar carga a infraestructura compartida. Avoiding fallback in distributed systems.

Ejemplo de cells

En Architecture A, todas las compras consultan una única capacidad compartida de Payment. Su agotamiento puede afectar a todos los tenants y bloquear otros flujos si también comparten workers. En Architecture B, diez cells tienen recursos y datos separados, y cada tenant se asigna a una de ellas.

Si una cell falla y la separación funciona para ese escenario, el impacto inicial puede quedar en su subconjunto. No necesariamente corresponde al 10 % del tráfico: distribución desigual y tenants grandes cambian la proporción. Un router global defectuoso o un despliegue simultáneo todavía puede afectar a las diez.

La guía de AWS sobre cells también vincula alcance con despliegue gradual y unidades de capacidad comprobables. Es una opción para requisitos de aislamiento, no una obligación para cualquier sistema. Why use a cell-based architecture?.

Prevención y recuperación

Reducir scope de cambios, limitar permisos y reservas compartidas, y comprobar dependencias puede contener exposición. Mantener instancias o regiones diferentes no prueba independencia si reciben la misma configuración defectuosa o requieren un control central para seguir atendiendo.

En recuperación, no trasladar tráfico indiscriminadamente a destinos sanos sin margen. Un rollback puede restablecer software, pero no deshace automáticamente efectos de negocio o datos ya modificados. La reintroducción masiva de pendientes puede causar thundering-herd y ampliar el incidente otra vez.

Uso y trade-offs

Usar blast radius para comparar escenarios, revisar cambios y priorizar aislamiento donde importa el impacto. No tratarlo como una garantía absoluta ni como sinónimo de severidad. Aislar más puede elevar costo, duplicar operación y dificultar transacciones o redistribución; centralizar puede simplificar esas tareas y ampliar el alcance de ciertos fallos. Ese cambio en exposición y compromisos es una señal de architectural-significance: merece atención por sus consecuencias sistémicas, aunque la modificación inicial sea pequeña.

Validar hipótesis con escenarios de fallo y recuperación, observando población, funcionalidades, datos y duración. failure-dynamics conecta esa evaluación con propagación, sincronización y feedback; describe cómo crece o persiste el impacto, sin confundirlo con su probabilidad.