Resilience Is a Customer Commitment. Not a Technology Standard.
Why the most expensive resilience investments are frequently protecting the wrong things.
Can you name which parts of your customer journey your customers consider genuinely critical, and which they would tolerate degraded during an outage?
If that conversation has not happened, the resilience architecture built in its absence is protecting assumptions rather than commitments.
The Wrong Starting Question.
Most resilience conversations begin with technology.
How much redundancy is needed? What is the failover capability? What availability target should the platform be designed to meet? These are reasonable questions. They are also the second questions. Not the first.
The first question is this. What does the customer actually need this system to do, and what is their tolerance when it cannot do it fully?
Without that answer the technology conversation has no anchor. It optimises for technical perfection rather than customer commitment. The result is a resilience architecture that is simultaneously over-engineered in some places and wrong-engineered in others.
Over-engineered because without customer criticality definitions the default is to protect everything at the highest level. Every component receives maximum resilience treatment regardless of its position in the customer journey or the customer’s actual tolerance for its unavailability. The cost is significant. The commercial justification is weak.
Wrong-engineered because the application-layer resilience that would have protected the customer journey during a partial failure was never built. The graceful degradation. The throttling. The stand-in patterns. Nobody translated the customer journey into the application-layer requirement it implied. Infrastructure was hardened. The customer experience remained fragile.
Both failure modes emerge from the same absence. The customer lens was not present when the resilience conversation began.
What I Observed Directly.
During a major platform build I was part of, the resilience architecture was designed before customer criticality had been defined.
The team was technically capable. The intent was genuine. But without knowing which parts of the customer journey were genuinely critical, which could tolerate degradation, and which needed full protection, the architecture defaulted to the most demanding scenario across the entire platform.
Every component was treated as if its unavailability were equally catastrophic. Infrastructure redundancy was sized accordingly. The investment was significant.
What the investment did not produce was application-layer resilience connected to specific customer journeys. The question of which journeys could degrade gracefully, which could be throttled under load, and which required a stand-in capability to maintain the customer experience during a primary system failure was never asked in the architecture conversation. It was a technology conversation designing to a technical standard rather than a business and technology conversation defining a customer commitment.
The platform was delivered. It worked. But the resilience investment was disproportionate to what the customer actually needed, and the specific protections the customer most needed were the ones that had not been built.
Customer Criticality as the Governing Frame.
Not all parts of a customer journey carry the same criticality. This is the insight that changes the resilience conversation from a technical exercise to a joint business and technology responsibility.
A card payment authorisation journey has different criticality from a statement view journey. A real-time balance enquiry has different criticality from a historical transaction search.
The customer’s tolerance for unavailability, degradation, or delay varies significantly across these journeys. In some cases any failure is unacceptable. In others a degraded service, a delayed response, a reduced feature set, is entirely acceptable provided the core customer need is met.
Defining customer criticality is the joint responsibility that governs everything that follows in the resilience conversation. Business defines what the customer needs and their tolerance when it is unavailable. Technology derives the architecture from those definitions.
This reframes RPO and RTO as customer commitment expressions rather than technical parameters. Recovery Point Objective and Recovery Time Objective are not numbers to be set by the infrastructure team against a technical standard. They are commitments to be derived from the business’s understanding of customer tolerance. The question is not what the infrastructure can support. It is what the customer journey requires, and what does that demand of the infrastructure.
Had this framing been present in the platform build described above, three things would have changed. The infrastructure investment would have been tiered to customer criticality rather than uniform across the platform. The application-layer resilience requirements would have been defined before the architecture conversation began. The commercial justification for the resilience investment would have been connected to customer outcomes rather than technical standards.
The Three Layers of Customer-Connected Resilience.
With customer criticality as the governing frame, the three dimensions of resilience become customer protection expressions rather than technical specifications.
Headroom and redundancy connect to RTO. The recovery time the customer journey requires determines the redundancy investment needed. A card payment authorisation journey that requires near-instant recovery demands a different redundancy architecture from a reporting capability the customer can wait minutes or hours to access. Sizing headroom and redundancy from the customer’s RTO requirement rather than from a uniform technical standard produces an investment that is both appropriate and defensible.
Graceful degradation connects to customer journey criticality. Not every failure needs to be total. For many customer journeys a degraded service is significantly better than no service. Throttling as a specific mechanism reduces request volumes to protect core capability rather than allowing the full system to fail under load. The customer who receives a slower response is better served than the customer who receives no response at all. This is where the application-layer resilience conversation lives. Infrastructure redundancy protects against the system going down. Graceful degradation protects the customer experience when parts of the system are under stress. Both are necessary. The second is consistently under-invested in because it requires the customer journey to have been defined before the architecture conversation begins.
Blast radius containment connects to customer segmentation. When a component fails the question is not just whether the system recovers. It is which customers are affected and how the impact is bounded by design. A failure affecting a specific product type should not affect customers on other product types. A failure in a non-critical service should not prevent access to a critical one. Containing the blast radius is a customer protection decision as much as a technical one.
The Stand-In Architecture Pattern.
The stand-in architecture pattern is the most concrete expression of application-layer resilience and one of the most underutilised outside the domains where it has been established for decades.
In card payment authorisation, stand-in processing has been a standard resilience mechanism in financial services for a long time. When the primary authorisation system is unavailable, the stand-in processes transactions against a local authorisation table, applying predefined risk parameters to approve or decline transactions without real-time access to the primary system. The customer payment journey continues. The risk is managed within defined parameters. The primary system outage is invisible to the cardholder at the point of payment.
This is application-layer resilience in its most mature form. The customer commitment, card payment authorisation will be available, is maintained even when the primary infrastructure is unavailable. The stand-in does not replicate the primary system. It provides a defined, bounded, acceptable alternative that keeps the customer journey moving.
The same pattern is applicable across other domains where the cost of complete unavailability significantly exceeds the cost of operating with reduced capability. In digital banking, a stand-in for balance enquiry could serve cached balances during a core banking outage, maintaining the customer’s ability to check their position while the primary system recovers.
In each case the stand-in is not a technical fallback. It is a customer commitment fulfilment mechanism. Its design starts with the question. What does the customer minimally need this system to do, and what is the acceptable risk of providing that minimum outside the primary system.
That is a business question before it is a technology question.
The Commercial Defensibility of Customer-Framed Resilience.
Resilience investment framed as infrastructure redundancy always faces the same commercial challenge. The cost is visible and present. The benefit is hypothetical and future. The CFO who questions whether the organisation needs two of everything is asking a reasonable commercial question. The technology leader who cannot answer it in customer terms is having the wrong conversation.
Resilience investment framed as customer commitment protection is a different conversation entirely.
The cost is still visible and present. But the benefit is now expressed in terms the board and the CFO can evaluate. What is the cost of a card payment authorisation outage to a customer who cannot complete a transaction at point of sale. What is the cost of a digital banking outage to a customer who cannot access their account during a critical moment. What is the trust cost of a failure that was preventable with an investment the organisation chose not to make.
The joint business and technology ownership of the resilience conversation is what makes this framing possible. Business defines the customer commitment. Technology prices the investment required to honour it. The CFO and the board evaluate a commitment and its cost rather than a technical standard and its price.
That is a conversation that can be won before a failure occurs.
What Becomes Possible.
The organisations that get resilience right do not have better infrastructure than those that do not.
They have a better conversation. One that starts with the customer journey, defines the commitment, and derives the architecture from what the customer actually needs rather than what the technology function assumes they need.
Resilience is not a technology problem that occasionally affects customers. It is a customer commitment that technology is responsible for honouring alongside the business that defined it.
The Sutra
Resilience begins with a question only the customer can answer. Most architectures are built before anyone asks it.