Skip to content

CONCEPT Cited by 20 sources

Blast radius

What it is

Blast radius is the scope of damage that a single fault — bug, misconfiguration, vulnerability, runaway workload, compromised credential — can reach before isolation mechanisms contain it. System design choices trade off blast-radius size against operational complexity and cost:

  • Smaller blast radius ⇒ safer failure modes, but more boundaries to provision/maintain/monitor.
  • Larger blast radius ⇒ simpler ops, cheaper substrate, but a single fault can affect many customers / regions / products.

The term is the concrete unit architects use when discussing isolation trade-offs: "what's the blast radius of this change?" is the design-review heuristic for rolling out anything risky.

Load-bearing in account-per-tenant isolation

One of the five benefits ProGlove cites for account-per-tenant:

"An accidental misconfiguration or vulnerability could expose multiple tenants."

…is a blast-radius framing. The AWS account boundary bounds the blast radius of any per-tenant fault to exactly one tenant's data + compute + IAM + network. In contrast, the shared-account shape makes the blast radius the whole tenant fleet. (Source: sources/2026-02-25-aws-6000-accounts-three-people-one-platform)

Named blast-radius boundaries in the wiki

Roughly ordered by decreasing size:

  1. AWS partition — sovereignty / jurisdictional boundary; aws-partition.
  2. AWS Region — availability / geographic boundary.
  3. AWS Availability Zone — DC-fault boundary.
  4. AWS account — security + quota + billing + IAM boundary. (concepts/tenant-isolation)
  5. Kubernetes cluster / EC2 fleet / service deployment — operational-unit boundary. (concepts/blast-radius, multi-cluster-active-active-redundancy)
  6. Tenant — authorization boundary inside a shared environment. (concepts/tenant-isolation)
  7. Database shard — storage-tier failure-domain boundary; concepts/cell-based-architecture. A shard's outage caps customer-impact to ~1/N of the fleet under uniform distribution. One-step-below cluster-level isolation and one-step-above tenant-level authorization.
  8. Request — the unit a single fault might affect.
  • concepts/blast-radius — same concept at the service/cluster level: running services across multiple active clusters so that any single cluster failure doesn't take the whole service down.
  • concepts/performance-isolation — performance-domain cousin; "how large a perf regression can one tenant cause for another?"
  • cross-partition-failover — blast-radius response at the largest possible scope (partition-level human-disaster containment).

Caveats

  • Blast radius ≠ 0 is not always the goal. Making the radius smaller costs more (more accounts, more clusters, more separate fleets). The right size is set by regulatory requirements, customer commitments, and economic feasibility, not a universal "smaller is better."
  • Structural boundaries vs application-level boundaries. An account boundary is load-bearing whether or not the application is multi-tenant-aware; a per-request tenant_id check is only load-bearing if the code path actually enforces it. Structural boundaries are the ones that survive bugs.
  • Cross-boundary primitives re-introduce risk. Anything that works "across" a blast-radius boundary — cross-account IAM roles, multi-region replication, shared admin tooling — lives outside the boundary and must be hardened separately. ProGlove's explicit call-out: "Observability tooling should be centralized, but without reintroducing the very risks that accounts are meant to isolate."

Seen in

  • sources/2026-09-29-cloudflare-building-a-certificate-authority-for-the-whole-internet — "fail small" applied to a certificate authority. Cloudflare's announced public CA (systems/cloudflare-certificate-authority) is designed so reliability depends "not just on avoiding mistakes" but on limiting the impact of any one issue, with recovery designed and tested before an incident. The concrete instance: because renewal automation (ARI / RFC 9773) is a condition of issuance, a mass revocation (compliance or security) is contained by bringing renewal windows forward, spreading replacements across available time, and tracking replacement issuance — instead of the classic CA bind of timely-revocation-vs-uptime. Separately, a redundant free CA is itself blast-radius reduction for the whole free-cert layer (if the one dominant free CA "had a bad week").

  • sources/2026-09-29-cloudflare-adaptive-application-security-for-the-ai-era-how-cloudflare — the containment question at the core of AI-era application security. Drawing on the July 2026 OpenAI / Hugging Face compromise (where network restrictions were bypassed by Internet-connected services and valid credentials performed unauthorized actions), the framework reframes defense from "can we patch before exploitation?" to "when one credential/path is compromised, how far can the attacker get?" — the same architecture-over- patching framing as 2026-06-09. Overlapping independent controls across the four runtime layers bound how far a chained compromise can propagate.

  • sources/2026-09-16-spotify-ai-changed-how-spotify-builds-quality-at-higher-velocity — time-window blast radius for fleet automation. After an automated dependency upgrade passed checks but failed in production, Spotify began scheduling automated fleet changes during the owning team's working hours so a human who understands the component is present when it lands — shrinking the blast radius of an unexpected regression along the time axis (bounded exposure window, fast human response) rather than the resource axis.

  • sources/2026-09-15-cloudflare-workers-granular-authorization — credential-scope blast radius for agents and CI: Cloudflare's resource-scoped Worker roles let you mint an API token scoped to one Worker so a compromised agent or leaked CI token "can deploy changes to that Worker, but it cannot delete it or touch any other application in your account." The Editor role deliberately withholds create/delete, and route changes require a composed Worker+zone permission rather than broad zone access — each a boundary that shrinks what a single misused token can reach. Canonical least-privilege-as-blast-radius-control instance on the non-human-identity axis.
  • sources/2026-07-20-spotify-content-ingestion-podcast-video-incident-report — a latency-not-availability blast radius: Spotify's June 24 2026 transcoding saturation never took the pipeline down, but the impact radius was every video-podcast creator publishing during the window (hours of delay). Priority queue tiers (medium=new, low=updates) are a blast-radius control — isolating real-time creator work from background re-processing — that proved too soft under a spike + batch job. See priority-based-queue-scheduling and time-to-detection (the ~4-hour recognition gap that extended the impact window).
  • sources/2026-08-24-grafana-from-failed-check-to-real-user-impact-pairing-synthetic-monitoring-and-frontend-observability — blast radius framed as the question a synthetic check structurally cannot answer ("a failing check tells you a user will fail; it cannot tell you how many real users have already failed") and that real user monitoring supplies. The canary analogy: synthetic monitoring warns the air has gone bad but can't say how many people are breathing it. Quantified blast radius ("~8% of EU users since 09:07") is what turns an alert into a data-driven incident priority. See synthetic-alert-to-rum-pivot and closed-loop-reliability.

  • sources/2025-06-20-redpanda-behind-the-scenes-redpanda-clouds-response-to-the-gcp-outage — canonical wiki instance of cell-based architecture as an explicit blast-radius reduction strategy. Redpanda's single-binary broker + per-customer cluster deployment bounds the blast radius of any fault to one customer's cluster; the 2025-06-12 GCP global outage validated the design — "Out of hundreds of clusters, we were lucky that only one cluster was affected." Explicit contrast with "centralized metadata and diskless" streaming architectures that "likely experienced the full weight of this global outage."

  • — Canonical wiki application of blast-radius containment to the webhook-sender service tier (Mike Coutermarsh, 2023-11-21, re-fetched 2026-04-21). PlanetScale runs its webhook sender as a dedicated Kubernetes service on isolated machines so webhook-specific abuse (SSRF attempts, amplification floods, slow-receiver resource-tie-up) is structurally bounded to the webhook tier. Verbatim: "In the event that our other mitigations fail, we run our webhooks queue on isolated machines to protect against webhooks impacting the availability of other PlanetScale services. … If our webhooks are being abused, we do not want that to impact the reliability of the rest of our systems. They can be easily paused or disabled in the event of an incident." Adds the isolated-service-per- failure-mode rung to the blast-radius ladder at the Kubernetes-service altitude — one step below fleet/cluster and one step above tenant. Composes with patterns/agent-sandbox-with-gateway-only-egress and defense-in-depth-webhook-abuse-mitigation.

  • — Brian Morrison II (PlanetScale, 2023-11-20) canonicalises horizontal sharding as a database-tier blast-radius primitive. The sharded-failure-domain framing: "in sharded environments, this failure domain is actually spread out. [...] If shard A goes down, it will make a bad day for customers 1-5, but the remaining shards are actually still online and can serve data with no problem." Adds the shard-rung to the blast-radius ladder above — a structural boundary below cluster and above tenant. Introduces the "two is one, and one is none" infrastructure adage as the load-bearing motivation for putting a shard boundary between customer and database. Also names the revenue-loss-containment corollary: a 1/N availability blast radius implies a ~1/N revenue-loss blast radius under uniform distribution. See concepts/cell-based-architecture for the full concept page.

  • sources/2026-02-25-aws-6000-accounts-three-people-one-platform — ProGlove's primary framing for the account-per-tenant architectural choice; blast-radius containment is one of five named benefits.

  • sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty — partition-level blast radius (human-disaster / geopolitical containment) addressed by cross-partition-failover.
  • sources/2025-09-25-mongodb-carrying-complexity-delivering-agility — MongoDB's dedicated-cluster framing of architectural isolation is explicitly a blast-radius containment claim: "with a MongoDB Atlas dedicated cluster… the blast radius of a problem elsewhere stops at your door." The anti-shared-wall stance is a boundary-per-tenant-at-VM-and-VPC rung on the blast-radius ladder, one step below account-per-tenant.
  • sources/2026-04-21-airbnb-building-a-fault-tolerant-metrics-storage-system — blast-radius reasoning stacked at two altitudes simultaneously: (1) concepts/shuffle-sharding inside a cluster bounds any single tenant's damage to their K-node shuffle set; (2) multi- cluster architecture with dedicated clusters for specialised workloads (compute / mesh / application tiers) bounds cluster-scoped failures to 1/N of the fleet. Rollout ordering (patterns/progressive-configuration-rollout) bounds the blast radius of deploy regressions along a criticality axis — test → internal → application → infrastructure clusters, with infra last so a regression doesn't cause "flying blind".
  • sources/2025-10-23-slack-advancing-our-chef-infrastructure-safety-without-disruption — Blast-radius reasoning at the fleet-configuration- management substrate altitude. Slack's phase-2 Chef rollout splits a single prod Chef environment into six AZ-bucketed environments (prod-1 … prod-6), mapping each new instance to its AZ's bucket at boot via Poptart Bootstrap. The load- bearing insight is that per-node cron staggering doesn't protect the newly-provisioned-nodes axis: "any newly provisioned nodes would immediately pick up the latest (possibly bad) changes from that shared environment. This became a significant reliability risk, especially during large scale-out events, where dozens or hundreds of nodes could start up with a broken configuration." The AZ-bucketed split is a cell-based-architecture instantiation at the configuration-management altitude — see az-bucketed-environment-split and patterns/cell-based-architecture-for-blast-radius-reduction. The post also canonicalises the architectural ceiling of the pattern (per-service isolation) as the motivation for building Shipyard as the legacy EC2 platform's successor.
  • sources/2024-12-12-stripe-the-secret-life-of-dns-packets-investigating-complex-networks — Stripe's central DNS-server cluster as a canonical choke-point at infrastructure boundary failure mode. The AWS VPC resolver's 1,024-pps-per-ENI rate limit turns any small cluster of ENIs that fronts DNS for a large fleet into a hard saturation ceiling; a Hadoop reverse-DNS workload filled it every hour. The fix is a blast-radius-reduction move at the topological altitude: distribute the DNS-forwarding workload off a few central ENIs onto every application host's local Unbound, so one ENI's saturation is localised rather than fleet-wide. See distribute-dns-load-to-host-resolver.

  • concepts/blast-radius — related cluster-level shape.

  • sources/2024-01-22-zalando-tale-of-metadpata-the-revenge-of-the-supertools — Blast-radius framing at the destructive-automation altitude. Zalando's 2024-01 postmortem of a November 2022 DNS outage names a new class — the supertool: an application with fleet-wide destructive authority that runs on a normal- looking config change. A single p-typo (metadata → metadpata) collapsed an account-lifecycle job's account-in-scope set to empty, which its decommission logic interpreted as "all accounts", triggering Route 53 hosted-zone deletion fleet-wide. The 5-layer containment stack Zalando shipped after the incident is a blast-radius-reduction recipe: scream test (1-week reversible Network ACL + DNS delegation removal), cost-weighted deletion deferral (low-savings resources excluded from automation entirely), PR preview of CloudFormation ChangeSet (per-account delta visible in review), triple- redundant jsonschema validation (IDE + pre-commit + CI on one schema), and phased rollout across release channels (playground → test → infra → production). Adds a new rung to the blast-radius ladder at the destructive-automation-applied-across- accounts altitude — see concepts/blast-radius.

  • sources/2026-04-24-atlassian-rovo-dev-driven-development — five-lever blast-radius safety net for agent-driven development. The Fireworks post explicitly reframes blast-radius as the load-bearing safety net when manual code review is no longer the primary correctness gate. Five named levers: "CI/CD pipelines (automated quality gate), Sharding (limit the blast radius of any single change), RBAC / JIT access (control who — and what — can write), Progressive rollouts & canary deploys across multiple clusters, AI-written e2e tests (primary validation harness)." Canonical wiki disclosure of sharding + RBAC + JIT + canary rollout as the defence-in-depth stack specifically targeted at LLM-written production code; "dev shards" (dev-shard-iteration-loop) provide the per-developer blast-radius bulkhead during development, and "canary deploys across multiple clusters" provide the production-rollout bulkhead. rbac-jit-as-agent-safety-net names the access-control lever explicitly. First wiki framing of blast-radius as the access-control-and-exposure tier that compensates for weakened manual-review gates in agentic development.

  • sources/2026-05-27-databricks-how-the-lakebase-architecture-stays-resilient-to-cloud-failures — Canonical quantified production-AZ-outage instance of cell-as-blast-radius-unit at the serverless-database regional-composition altitude. systems/lakebase composes each region from N identically-shaped cells (each a complete Kubernetes + control plane + compute + storage stack); during the 2026-05-08 AWS us-east-1 thermal-event AZ outage, "one of the cells had issues failing over to healthy nodes. The impact was contained to that cell. The other seven cells in the region failed over correctly, so the incident affected only ~13% of databases in the region. In this case, the cell-based architecture reduced the impact by roughly an order of magnitude." The canonical-instance datums: 8 cells in us-east-1 (~13% impact = ~1/8 = the cell ratio); 7 cells failed over correctly + 1 imperfectly during the AZ event. New rung in the blast-radius ladder at the regional-cell-composition altitude — one step below "AWS Region" (since cells are within-region) and one step above "Kubernetes cluster" (since each cell is a Kubernetes cluster + supporting stack). Distinct from Redpanda's per-customer-cluster cells (customer-bounded) and from AWS Hybrid Multi-Tenant cells (AWS-account-bounded) — Lakebase's cells are fleet-bounded multi-customer cells inside a single regional AWS account. First wiki canonical instance of:

  • Quantified production-AZ-outage blast-radius validation on a serverless-database regional architecture.
  • Cell as scaling-unit-and-blast-radius-unit jointly — the cell boundary is sized by Kubernetes + control-plane scaling limits, not by a customer / AWS-account boundary.
  • Whole-AZ-network-partition drill regime sized to one cell — see concepts/chaos-engineering + whole-az-network-partition-drill; the cell boundary is what makes the drill safe.

Blast radius in streaming infrastructure (Atlassian StreamHub)

At 150B events/day, Atlassian uses three complementary blast-radius controls:

  1. Cluster sharding — split the streaming fleet into multiple independent Kafka clusters; an incident in one shard only affects that fraction of traffic. See patterns/cell-based-architecture-for-blast-radius-reduction.
  2. Client quotas — per-client producer_byte_rate / consumer_byte_rate budgets prevent one misconfigured pipeline from monopolizing shared broker resources. "Quotas are not only a cost control mechanism. At StreamHub scale, they are a blast radius control."
  3. Failover cluster escape hatch — when the managed control plane is stuck, operators can provision a clean cluster and reroute traffic entirely, without depending on the failing cluster's management APIs. See failover-cluster-escape-hatch.

(Source: sources/2026-07-28-atlassian-scaling-streamhub-transitioning-from-kinesis-to-kafka)

Blast radius in event delivery (Atlassian Events Rail)

At 10B events/month, Atlassian's Events Rail uses per-recipient concurrency limiting as the mechanism that makes blast-radius containment work at the delivery tier:

  • A slow recipient's in-flight deliveries pile up against its own cap — further deliveries are deferred, not dispatched.
  • The limit is cluster-wide (shared counter across all pods) so no single pod assignment can circumvent it.
  • The two-stage pipeline (matching → queue → delivery) provides structural containment: a slow recipient stays a delivery-side concern while matching keeps producing decisions into the queue.

"A silently dropped event is a much worse failure than a slightly delayed one" — so the system defers rather than drops, bounding blast radius without sacrificing durability.

(Source: sources/2026-07-29-atlassian-inside-the-events-rail)

Merged aliases

  • blast-radius-multiplier-at-fleet-scale
  • control-plane-change-blast-radius
  • destructive-automation-blast-radius
  • destructive-testing-with-zero-blast-radius
  • regionalization-blast-radius-reduction
  • topology-aware-blast-radius- fault-domain-scaling
  • isolation-as-fault-tolerance-principle
  • operational-efficiency-vs-risk-isolation-tradeoff
  • region-scale-failure- active-multi-cluster-blast-radius
  • tld-level-failure-blast-radius
Last updated · 766 distilled / 2,225 read