Resilience by design: start with failure modes.

Failure is an input, not an exception

Every architecture contains assumptions about power, connectivity, timing, people, dependencies, and recovery. When those assumptions remain implicit, they become hidden failure modes. The architect's first task is to make them visible.

I prefer to begin with a simple question: What must still work when this component does not? The answer creates a clearer design conversation than a list of availability features. It tells us which services are essential, how long disruption is acceptable, and where graceful degradation is more valuable than complex automatic recovery.

Find the blast radius before the product

A component can be highly available while the service around it remains fragile. Shared dependencies, common management planes, incorrect failure domains, and operational procedures can turn two devices into one point of failure with twice the cost.

Before selecting technology, map the blast radius. Identify which users, sites, functions, and recovery paths are affected by each plausible event. This changes the design from a diagram of devices into a model of service continuity.

Design the degraded mode

Operational importance does not mean every capability must remain perfect. It means the essential capability must remain understood. A strong architecture defines degraded modes deliberately: which traffic is prioritised, which functions pause safely, what operators can see, and how the system returns to normal without creating a second incident.

• Define the minimum viable service for each critical scenario.
• Keep recovery paths independent from the failure they are meant to solve.
• Make state, ownership, and operator actions unambiguous.
• Test transitions—not only steady-state availability.

Operability belongs in the architecture

Monitoring is frequently treated as a layer added after implementation. That is too late. If operators cannot determine what changed, what is affected, and whether recovery is progressing, the architecture is incomplete.

Useful telemetry follows the service model. It connects infrastructure signals to user impact and creates evidence for decisions under pressure. Logs, flows, health checks, packet captures, and dashboards are tools; observability is the design of understanding.

Resilience is also organisational

The final failure domain is often unclear responsibility. Architecture must establish who owns a dependency, who can make a change, who decides during an incident, and which knowledge must exist outside one person's head.

This is why standards, documentation, rehearsals, and partner alignment are not administrative work around the architecture. They are part of the system. Technology can provide options; prepared teams turn those options into resilience.