CodeRadius LogoCodeRadius Docs
Explore

Blast Radius Scoring

Understand how CodeRadius classifies the risk of changing or breaking an architectural node using the Downstream Gravity Score and Impact Tiers (T0–T4).

Blast Radius Scoring

The Impact Explorer assigns every architectural node — Service, Database, Message Channel, API Endpoint — a Downstream Gravity Score that quantifies the risk of that node failing or being modified. This score is then mapped to an Impact Tier (T0 through T4) for human-readable risk classification.

The gravity score is pre-computed during dashboard generation. The Impact Explorer UI performs zero graph computation — it reads the score directly from each node.


Impact Tiers

Every node in the architecture graph is classified into one of five tiers based on its gravity score:

TierLabelScore RangeWhat It Means
T0Seismic≥ 100An outage cascades across the entire organization. Think: core shared database with 30+ reader services, or the central event bus.
T1Critical50 – 99Multi-team incident probable. A failure here breaks production for multiple domains.
T2High15 – 49Significant blast radius. Changes require cross-team coordination and formal review.
T3Moderate6 – 14Localized impact. Standard change management is sufficient.
T4Contained0 – 5Isolated leaf node. Safe to modify with minimal coordination.

How the Score Works

The gravity score answers a single question: "If this node dies, how much of the architecture breaks?"

Core Principle: Downstream Gravity

The score is based exclusively on downstream impact — the nodes that would be directly or transitively broken. It does not factor in upstream dependencies (those make you fragile, not dangerous).

What Makes It "Weighted"

Unlike a simple connection count, the gravity score weighs each downstream dependency by its connectivity. A downstream node that is itself a critical hub (with many connections) contributes more weight than an isolated leaf. This ensures that breaking a resource used by a critical hub service is scored higher than breaking one used by a standalone worker.

Worked Examples

Example 1: Standalone email worker

  • Topology: email-worker → (LISTENS_TO) → notifications
  • The worker has zero downstream impact — if it breaks, nothing downstream is affected.
  • Gravity Score: 0 → T4 Contained

Example 2: Service writing to a shared database

  • Topology: order-service → (WRITES) → orders_db ← (READS) ← reporting-service, analytics-service, ...8 others
  • The orders_db table is used by 8 reader services. If order-service corrupts the data or the table schema changes, 8 downstream consumers are impacted.
  • The downstream nodes each have moderate connectivity, and their degree is factored into the weight.
  • Gravity Score: ~16 → T2 High

Example 3: Event bus producer

  • Topology: payment-service → (PUBLISHES_TO) → payment.completed ← (LISTENS_TO) ← 12 consumer services
  • If payment-service stops publishing events, 12 downstream consumers receive no data.
  • Gravity Score: ~22 → T2 High

Example 4: Enterprise-scale data monolith

  • Topology: identity-service → (WRITES) → core_users ← (READS) ← 30 reader services
  • A massive shared database. An outage in the writer or a schema migration cascades to 30 downstream teams.
  • Gravity Score: ~72 → T1 Critical

Interpreting the Banner

When you select a node in the Impact Explorer, the Target Banner shows:

ElementSource
Tier Badge (T0–T4)Derived from the pre-computed gravity score
Direct countNumber of Tier 1 (1-hop) downstream + upstream nodes
Transitive countNumber of Tier 2 (2-hop) nodes reached via passthrough resources
Upstream countNodes this target depends on (informational — not part of the tier score)
Teams countUnique teams in the blast radius (informational)

The Upstream count in the banner is displayed for context only. It tells you how fragile the node is (what it depends on), but does not contribute to the gravity score or tier classification.


When a High Tier Is Acceptable

Not every T0/T1 score requires immediate action:

  • Authentication services — A central identity-service will naturally score T1 or higher. The mitigation is operational (redundancy, circuit breakers), not architectural.
  • Event buses — A core message broker concentrates connections by design. Monitor the SPOF score in the SPOFs dashboard for concentration risk.
  • API gateways — A shared API gateway serving many consumers will score high. Ensure it has horizontal scaling and rate limiting.

When to Act

Prioritize action when:

  1. T0 or T1 with no redundancy — The node is critical but has no failover, circuit breaker, or graceful degradation strategy.
  2. Cross-team T2+ — Multiple teams depend on a single resource with no formal data contract or API versioning.
  3. Tight schema coupling — Services read directly from a shared database table without an abstraction layer (API or view).
  4. No ownership — The high-scoring node has no assigned team owner (see Governance).

Relationship to SPOF Analysis

The gravity score and the SPOF Score measure related but distinct things:

DimensionGravity Score (Impact Explorer)SPOF Score (Data Gravity)
Question"What breaks if I die?""How concentrated are my dependents?"
ScopePer-node, including servicesData resources and service bottlenecks only
AlgorithmDownstream 2-hop with degree weightingFan-in/fan-out with team diversity
RangeUnbounded integer → T0–T4 tier0–100 asymptotic curve

Use both together: the SPOF dashboard identifies which resources are dangerously concentrated, and the Impact Explorer shows what happens when one of those resources fails.


Further Reading

On this page