Blast Radius

Defining the Radius

 BLAST RADIUS = everything harmed when component X fails:

 small radius:  one feature degrades for some users
 large radius:  platform-wide outage, data corruption,
                cascading to other systems

 radius dimensions beyond "is it down":
 - WHICH users (all? a shard? a tenant?)
 - WHAT harm (unavailable? wrong answers? LOST DATA?)
 - HOW LONG (auto-recovery vs manual archaeology)

 the worst radii combine: silent + widespread + data-affecting.

Radius by Change Type

Change	Typical radius	Limiter
Config flag flip	everything reading it	staged rollout + validation
Schema migration	every query on table	expand/contract, online tools
Bad deploy	service + its callers	canary + auto-rollback
Cache flush	DB stampede behind it	staggered warming
Deleted queue/topic	all its consumers	soft-delete, backups
Wrong permission grant	security-wide	least privilege, audits

 pattern: radius scales with SHARING.
 shared config, shared caches, shared credentials,
 shared databases — each shared thing is an antenna
 broadcasting failures outward. minimize sharing or gate it.

Shrinking Radii Deliberately

 □ STAGED ROLLLOUTS: 1% → 10% → 50% → 100% with health gates;
   a bad change's radius = the canary cohort only ✓
 □ ENVIRONMENT SEPARATION: prod creds/infra unreachable from
   staging scripts (the classic dropped-table horror)
 □ PERMISSION GRANULARITY: deploy keys ≠ admin keys ≠ app keys
 □ DESTRUCTIVE-ACTION FRICTION: multi-approval for drops,
   deletes, region-scale operations; dry-run modes
 □ IDEMPOTENT+REVERSIBLE ops design: every mutation has an
   inverse documented BEFORE running
 □ RATE LIMITS ON CHANGE: even correct automation misfiring
   at 1000 ops/s is a different incident than 10/s

The Data-Corruption Radius

 hardest class: wrong WRITES propagate silently.

 bad event published → consumed by N services → N corrupted stores.

 limiters:
 □ schema validation AT INGEST (bad data rejected early)
 □ consumer-side invariant checks before applying
 □ REPLAYABLE sources: corruption repairable via replay
   (event-sourcing/CDC shine here)
 □ RECONCILIATION sweeps comparing derived stores to source
 □ BACKUPS with integrity checks (restore-tested! DR lessons)

 ask per write path: if this writes garbage for 1 hour,
 how long to detect? to bound? to repair? — have numbers.

Interview Framing

“What limits the damage of a bad deploy in your design?” scored shape: staged rollout with auto-rollback gates as primary limiter, sharing-reduction principle named, destructive-action friction for ops paths, data-corruption scenario addressed via validation+replay+reconciliation. Blast-radius vocabulary itself signals maturity — designs are judged not just by working, but by failing SMALL.