A deployment introduces a defect.
The immediate question is:
What broke?
The more architectural question is:
How much was able to break with it?
Perhaps one service became unavailable.
Perhaps every service in the environment restarted.
Perhaps a shared cluster failed.
Perhaps a platform controller changed resources across several cloud accounts.
Perhaps a compromised identity reached production, backups and audit logs.
The initiating event matters.
So does the distance the event was allowed to travel.
That distance is the blast radius.
Blast radius is the potential scope of impact that an initiating event can reach through authority, dependency or shared state before effective containment intervenes.
The term is often used for security incidents or cloud accounts.
But the principle appears almost everywhere:
- service boundaries
- networks
- identity
- deployments
- databases
- queues
- clusters
- regions
- infrastructure state
- observability
- backups
- platform APIs
- organisational ownership
Once I began looking for blast radius, I found it hiding inside many decisions I had previously described using different language.
Why separate environments?
To reduce blast radius.
Why give services separate identities?
To reduce blast radius.
Why deploy gradually?
To reduce blast radius.
Why keep backups outside production?
To reduce blast radius.
Why separate platform control planes from application workloads?
Again, blast radius.
The principle does not say that every system should be divided into the smallest possible pieces.
It gives me a question:
When this component, identity or change fails, what else is permitted to fail with it?
That question turns system boundaries into deliberate engineering choices.
A practical blast-radius model
Blast radius is not one number.
A failure can spread across several dimensions.
RESOURCE SCOPE
Which systems or assets
can be affected?
USER SCOPE
Which customers or operators
experience the impact?
AUTHORITY SCOPE
Which resources can an identity
or controller change?
DATA SCOPE
Which records, tenants or domains
can be exposed or corrupted?
TIME SCOPE
How long can the impact continue
or accumulate?
GEOGRAPHIC SCOPE
Which zones, regions or providers
share the failure?
RECOVERY SCOPE
Which evidence and recovery tools
remain usable?
It is also useful to distinguish potential from realised impact.
POTENTIAL BLAST RADIUS
the maximum impact permitted
by the architecture
REALISED IMPACT
the damage produced
by this particular incident
A powerful administrative role may have an enormous potential blast radius even when one mistaken command changes only one resource.
A shared database may expose several services to one outage even if only one service is currently affected.
The architecture determines what could be reached.
The incident determines what actually was.
A reusable model is:
INITIATING EVENT
│
▼
PROPAGATION OR COMMON-MODE PATH
│
▼
POTENTIAL IMPACT
│
▼
CONTAINMENT BOUNDARY
│
▼
REALISED IMPACT
For each design, I now ask:
What initiates the event?
How can impact travel?
What kind of harm can occur?
Which boundary should contain it?
What evidence shows that the boundary holds?
Wide impact has more than one mechanism
Some failures propagate from one component to another.
SLOW DEPENDENCY
│
▼
WAITING CALLERS
│
▼
RESOURCE EXHAUSTION
│
▼
CALLER FAILURE
Other failures are common-mode.
SHARED DNS FAILURE
│
├── catalog unavailable
├── basket unavailable
└── order unavailable
The services did not necessarily infect each other.
They depended on the same failed capability.
A wide incident can therefore come from:
- propagation between components
- shared dependencies
- shared administrative authority
- shared data
- shared control planes
- shared change paths
The containment control depends on the mechanism.
Propagation may need timeouts, rate limits or circuit breakers.
Common-mode risk may need dependency separation or independent rollout.
Excessive authority may need narrower identities.
Shared change risk may need staged deployment.
A visible boundary is useful only when it matches the failure being considered.
VISIBLE BOUNDARY
does not automatically equal
EFFECTIVE CONTAINMENT
Authority defines administrative reach
An identity’s permissions describe how much it can affect.
Suppose every bfstore service uses one cloud role:
BFSTORE-WORKLOAD-ROLE
read and write all application buckets
read all application secrets
publish to all topics
modify all queues
A compromise of one service exposes the authority of all services.
ONE SERVICE COMPROMISED
│
▼
SHARED IDENTITY STOLEN
│
▼
ALL PERMITTED RESOURCES EXPOSED
Separate workload identities reduce that radius:
CATALOG IDENTITY
read catalog secrets
access catalog storage
PAYMENT IDENTITY
read payment secrets
publish payment events
ORDER IDENTITY
access order database
publish order events
The goal is not to create a policy for every function call.
It is to ensure that compromising one workload does not automatically grant the authority of unrelated workloads.
Least privilege is therefore a blast-radius control.
IDENTITY AUTHORITY
defines
MAXIMUM SECURITY IMPACT
The policy answers not only:
Can the workload perform its job?
but also:
What could an attacker do
after becoming this workload?
Administrative identities need stronger boundaries
Platform automation often has broader authority than application workloads.
Examples include:
- Terraform runners
- Crossplane providers
- GitOps controllers
- CI systems
- cluster administrators
- break-glass operators
A single automation identity spanning every account and environment creates an enormous potential blast radius.
The identities may use common code.
They should not necessarily share common authority.
A stronger design separates access by:
- account
- environment
- workload class
- resource family
- administrative function
Cloud accounts can reinforce that boundary.
They separate administration, billing, account-scoped quotas, logs, backups and workloads.
They are not impenetrable.
Organisation-wide roles, root credentials and central policies can still cross them.
The account remains useful because it creates a clearer unit for access, evidence and containment.
Central policy needs bounded rollout
An organisation-wide policy may affect every account beneath it.
Its value comes partly from that reach.
That reach also creates risk.
DRAFT POLICY
│
▼
STATIC VALIDATION
│
▼
POLICY-TEST ACCOUNT
│
▼
SANDBOX
│
▼
NON-PRODUCTION
│
▼
PRODUCTION
The control remains central.
Its rollout is bounded.
This is progressive delivery applied to governance.
The policy-test account is not bureaucratic decoration.
It is a blast chamber for organisational controls.
Dependencies define runtime reach
Service boundaries can reduce process-level failure.
A catalog failure does not need to terminate the payment process.
A review deployment does not need to replace order code.
But services may still share databases, clusters, networks or identity providers.
Microservices do not remove failure.
They change its shape.
Shared state reconnects separate services
Suppose catalog, basket and order use one database.
CATALOG ──┐
│
BASKET ───┼──► SHARED DATABASE
│
ORDER ────┘
The processes are separate.
The data failure domain is not.
A database outage affects all three.
A destructive migration may damage every service’s tables.
Service-owned databases provide stronger separation:
CATALOG ──► CATALOG DATABASE
BASKET ───► BASKET DATABASE
ORDER ───► ORDER DATABASE
The cost is a larger operating surface:
- more databases
- more backups
- more migrations
- more connection management
- harder cross-service consistency
Blast-radius reduction always has a price.
The question is whether the containment benefit justifies the operating cost.
Networks constrain communication, not all authority
A flat network lets a compromised workload reach every exposed dependency.
Segmentation can restrict that reach.
CATALOG SERVICE
may reach:
catalog database
telemetry endpoint
may not reach:
payment database
backup vault
management systems
Network boundaries control communication paths.
They do not replace identity controls over provider APIs and control planes.
A workload unable to connect to a database endpoint might still have permission to delete it through a cloud API.
One boundary limits reach.
The other limits authority.
Capacity limits contain noisy neighbours
A workload with no resource boundary can consume shared capacity.
Requests, limits, quotas, rate limits and concurrency controls turn unlimited propagation into bounded degradation.
FAULTY SERVICE
│
▼
NAMESPACE OR SERVICE LIMIT
│
▼
LOCAL DEGRADATION
A Namespace creates naming, policy and quota scope inside a shared Kubernetes control plane.
It does not independently contain control-plane failure.
Cluster boundaries, node-pool boundaries and administrative permissions still matter.
Timeouts, retries and circuit breakers limit temporal reach
A timeout limits how long a dependency can hold caller resources.
It should fit inside the caller’s end-to-end deadline and leave time for safe fallback or response handling.
Retries can recover transient failure.
They can also amplify it.
A safe retry policy uses:
- bounded attempts
- exponential backoff
- jitter
- deadlines
- retryable-error classification
- idempotency
A circuit breaker prevents every request from continuing to spend resources on a dependency already known to be failing.
Probe frequency and recovery behaviour should avoid sending every caller back at once.
These controls all ask:
How much additional work
may one dependency failure create?
Queues contain synchrony but accumulate time
A queue can let a producer continue while a consumer slows.
The immediate synchronous blast radius becomes smaller.
The backlog grows instead.
CONSUMER SLOW
│
▼
QUEUE DEPTH INCREASES
│
▼
PROCESSING DELAY INCREASES
The failure has changed form.
It is now temporal accumulation.
A queue is not a black hole into which failure disappears.
It is a reservoir.
Reservoirs need walls and overflow plans.
Changes define exposure
A deployment can replace every instance at once.
If the new version is faulty, the whole service is affected.
A canary or ring-based rollout narrows the first exposure.
NEW VERSION
small population
│
▼
OBSERVE
│
├── healthy ──► expand
└── unhealthy ► stop
Progressive delivery does not prove that a release is safe.
It limits how much is exposed before the organisation learns that it is not.
Feature flags can create a similar product boundary by limiting exposure to internal users, selected tenants or a percentage of traffic.
The flag remains useful when the boundary is explicit, observable and removable.
Infrastructure state limits one operation
A single Terraform state containing organisation, network, production, backups and observability creates a broad change scope.
Separate state can reduce the resources participating in one plan.
But state scope is not the whole boundary.
STATE SCOPE
what one plan contains
IDENTITY SCOPE
what the runner is authorised
to change
A runner with broad permissions can still cross several state boundaries.
Both the operation and the authority need containment.
Platform APIs multiply value and risk
A platform control plane applies one decision to many consumers.
AUTOMATION VALUE
one improvement applied widely
AUTOMATION RISK
one mistake applied widely
Platform changes need controls proportional to their reach:
- versioning
- automated tests
- test environments
- staged adoption
- previews
- compatibility policy
- rollback or forward repair
- consumer visibility
The greater the reach, the more deliberate the rollout should be.
Regions and clouds do not contain shared logic automatically
Multi-region infrastructure can reduce location failure.
It can also replicate the same defect everywhere.
FAULTY RELEASE
│
▼
DEPLOYED TO ALL REGIONS
│
▼
GLOBAL FAILURE
Multi-cloud behaves similarly.
It can reduce one provider-specific dependency while preserving a shared platform, credential, application or supply-chain failure.
The architecture should name the failure it intends to contain.
Otherwise multi-cloud resilience can become three times the infrastructure supporting one common mistake.
Evidence and recovery need separate boundaries
A production workload and its observability stack may share the same failure domain.
If the cluster fails, the system can lose both service and evidence.
Likewise, the identity that produces logs should not be able to erase them.
WORKLOAD
│
▼
EXTERNAL TELEMETRY BOUNDARY
The deeper reason for protected logging is survivability.
Backups must sit beyond the expected incident
A backup stored beside production may share:
- account permissions
- deletion authority
- ransomware exposure
- storage failure
- operator mistakes
A stronger design stores protected copies elsewhere with independent controls.
The goal is not merely another copy.
It is a copy beyond the expected radius of the initiating event.
A backup inside the blast is debris. A backup beyond the blast is recovery.
The same applies to:
- restore roles
- encryption keys
- artefact registries
- infrastructure definitions
- recovery documentation
Recovery tools that depend entirely on the failed system do not create an independent recovery path.
Ownership is also a containment boundary
One central team may own cloud accounts, networks, clusters, messaging, observability, databases, pipelines and every incident.
A staffing or knowledge failure in that team can affect the entire platform.
Clear ownership should distribute responsibility without creating hand-off theatre.
Application teams own application behaviour.
Platform teams own shared capabilities.
Security teams own central policy and detection.
Recovery owners maintain backup and restore services.
The architecture may be technical.
Its ability to recover is organisational too.
Choose proportionate containment
Smaller blast radius is not always better.
Extreme isolation can create:
one account per service
one cluster per service
one database per service
one pipeline per service
one observability stack per service
That reduces some shared failures.
It also multiplies:
- cost
- patching
- monitoring
- certificates
- backups
- upgrades
- operational skills
Poorly operated isolation can reduce resilience.
A forgotten backup in a dedicated account is not safer merely because it is separate.
The objective is:
A blast radius proportionate to the service’s criticality, threat model and the organisation’s ability to operate the resulting boundaries.
A review service and a payment service may justify different isolation.
Development and production usually do.
Tenant boundaries may also differ.
Separate schemas can improve organisational and policy scope, but they do not provide strong isolation when applications or administrators retain cross-schema authority.
Financial boundaries differ too.
Budgets and alerts are detective controls.
Quotas, capacity ceilings and approved profiles are preventive controls.
Both help answer:
How much can one mistake consume?
Test the containment claim
An architecture diagram can claim that failure is contained.
A test demonstrates whether the boundary holds under a defined scenario.
Identity
Can the catalog identity
read the payment secret?
Expected:
denied
Network
Can the review service
connect to the order database?
Expected:
denied
Capacity
Can one Namespace consume
all cluster capacity?
Expected:
bounded by quotas,
requests and limits
Deployment
Can a failed canary
reach every production user?
Expected:
no
Backup
Can a production administrator
delete the protected backup copy?
Expected:
denied or tightly controlled
Policy
Can an untested organisation policy
be attached directly to production?
Expected:
prevented by permissions
and rollout controls
The boundary should fail closed where appropriate.
It should also produce enough evidence to show what happened.
A bfstore blast-radius review
For bfstore, I would review the architecture through the same model.
INITIATING EVENT
faulty deployment,
compromised workload,
bad policy,
dependency failure
PROPAGATION OR COMMON MODE
shared identity,
shared database,
shared cluster,
shared control plane
EXPECTED BOUNDARY
service,
Namespace,
cluster,
account,
environment,
region
SURVIVING CAPABILITIES
logs,
backups,
recovery roles,
deployment tooling
The review would ask:
- Can development automation alter production?
- Can one service identity reach another service’s data?
- Can one workload consume all cluster capacity?
- Can one platform change reach every production consumer immediately?
- Will central logs and backups survive a production compromise?
- Can recovery proceed without the failed account or cluster?
Not every failure will stop at the first boundary.
The design should name which boundary is expected to stop each one.
Questions I now ask
Event
Which event are we considering?
First impact
What is affected first?
Mechanism
Does impact propagate,
or is there a shared failure?
Reach
Which authority, dependency
or state allows wider impact?
Harm
Which dimensions of harm
are possible?
Boundary
Which control should
contain the event?
Survival
Will evidence and recovery
remain available?
Test
Has a realistic exercise
demonstrated containment?
These questions turn blast radius into something more practical than a phrase placed beside a security diagram.
The mental model I am keeping
My earlier model was:
BLAST RADIUS
how many systems fail
during a major incident
The stronger model is:
INITIATING EVENT
│
▼
PROPAGATION OR COMMON MODE
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
DEPENDENCIES AUTHORITY SHARED STATE
│ │ │
└──────────────────┼──────────────────┘
▼
POTENTIAL SCOPE OF IMPACT
│
▼
CONTAINMENT BOUNDARY
│
┌─────────────┴─────────────┐
│ │
▼ ▼
CONTAINED ESCAPES
│ │
▼ ▼
LOCAL RECOVERY WIDER INCIDENT
Blast radius is not one feature added to an architecture.
It is a property produced by the relationships, permissions and shared systems already inside it.
Every database defines one.
Every administrative role defines one.
Every cluster, account, state file and deployment pipeline defines one.
The architecture determines how far a failure is permitted to travel before anybody knows which particular failure will occur.
That is why the principle is hiding everywhere.
Good architecture does not assume that failure can be eliminated. It decides in advance how much of the system any one failure is allowed to take with it.
The goal is not to build a world where nothing breaks.
It is to stop one broken thing from receiving an all-access pass to everything else.