Most resilience plans describe how a system returns to normal. They say less about what the business should do while normal is unavailable. That gap matters. During a dependency failure, teams often improvise the product behaviour under pressure: disable a page, accept transactions they cannot fully verify, show stale data without saying so, or stop the entire journey because one secondary service is unavailable.

A degraded mode is not a weaker version of the infrastructure. It is an explicit business and product decision about which capabilities remain available, with what guarantees, for how long, and under whose authority. If those decisions are made only during an incident, the architecture has already transferred too much risk to the incident channel.

Availability is not a single switch

A system can be technically online while its most valuable journey is unusable. It can also deliver meaningful service while several components are impaired. Treating availability as simply up or down hides this distinction.

Consider an order workflow that normally checks inventory, calculates a promotion, authorizes payment, estimates delivery, records the order, and sends notifications. Those steps do not necessarily have equal business importance or equal failure consequences. A notification can wait. A delivery estimate might be marked provisional. An inventory decision may require a reservation or a strict refusal. Payment handling may allow no ambiguity at all.

The useful architecture question is therefore not, “Can the application stay up?” It is, “Which business outcome can we still deliver safely when a particular dependency is unavailable?” That question creates a much more precise conversation between product, operations, security, finance, and engineering.

Start with the customer promise

Degraded-mode design should begin with journeys, not components. A component inventory tells you what can fail. A journey map tells you what that failure means.

For each critical journey, define a minimum acceptable outcome. That outcome may be complete service, delayed completion, read-only access, queued intent, or a clear refusal. “Best effort” is not a definition; it avoids the decision that engineers will still have to make in code.

A practical review should answer these questions:

• Essential outcome: What value must the customer still receive?
• Required evidence: Which facts must be current and authoritative before the action is accepted?
• Permitted delay: Which checks or side effects may complete later?
• Reconciliation: How will queued or provisional work be confirmed, corrected, or rejected?
• Communication: What will the customer and support team be told about the reduced guarantee?
• Exit condition: What evidence allows the system to return to normal behaviour?

This turns “keep it running” into an operable contract. It also exposes cases where stopping is safer than continuing. A deliberate refusal can be a successful degraded mode when proceeding would create duplicate charges, violate policy, or produce commitments the organization cannot honour.

Classify the fallback, not just the failure

Teams commonly document timeouts, retries, circuit breakers, and failover. Those are useful mechanisms, but they do not define the business semantics after the mechanism activates. A circuit breaker can prevent cascading resource exhaustion; it cannot decide whether the customer should see cached information, submit a request for later processing, or be blocked.

I find four fallback patterns useful:

1. Omit: Remove a nonessential capability, such as recommendations or notifications, while preserving the core transaction.
2. Read with qualification: Serve a known snapshot and disclose its age or limitations where that changes the decision.
3. Accept intent: Record an idempotent request for later processing without pretending the business outcome is complete.
4. Refuse safely: Stop the action with a precise explanation when authority, correctness, or compliance cannot be established.

These patterns should be chosen per journey and dependency. A global rule such as “use the cache when the database is down” is too blunt. The same stale value may be harmless for a catalogue description and unacceptable for an account balance.

Make uncertainty visible in the model

Many degraded modes fail because the data model has only two states: success and failure. Real workflows often need states such as pending validation, provisionally accepted, awaiting reconciliation, or rejected after review. If uncertainty is not represented explicitly, it leaks into logs, support notes, and manual spreadsheets.

Introduce an intermediate state only when the organization can operate it. Every provisional transaction needs an owner, a time limit, a replay or review process, and a customer communication path. A queue is not a recovery strategy by itself. It is a commitment to process a backlog under conditions that may differ from those at submission time.

Idempotency is equally important. Retrying a recorded intent must not create a second business action. The idempotency key, the scope of the guarantee, and its retention period should be part of the contract rather than an implementation detail known only to one service.

Put a boundary around the degraded mode

A fallback that is always available tends to become an undocumented normal path. Control it deliberately. Activation may be automatic for a narrow, well-tested condition or manual when the consequence requires business judgment. In either case, record why it activated, which guarantees changed, and how long it has been active.

Useful controls include a maximum duration, volume limits, eligibility rules, feature flags with audited ownership, and a kill switch. Observability should measure the business backlog and provisional outcomes, not only infrastructure health. A green CPU chart says little if thousands of accepted requests are waiting for reconciliation.

Test the promise, not merely the mechanism

A timeout test proves that a timeout occurs. It does not prove that the customer receives an honest message, that duplicate submissions are prevented, or that operations can clear the resulting backlog.

Exercise degraded modes as end-to-end business scenarios. Simulate the dependency failure, activate the intended fallback, restore service, reconcile the work, and verify the final customer and financial state. Include support and operational owners in the exercise. They will often find missing decisions that are invisible in a technical runbook.

Release criteria should cover both entry and recovery. Teams tend to test the switch into a fallback but give less attention to the return path. Recovery can be the more dangerous phase because delayed work, retries, live traffic, and manual actions converge at once.

Accept the tradeoffs explicitly

Degraded modes add code paths, states, tests, operational procedures, and customer messaging. They are not free resilience. For a low-value or low-frequency journey, a clear outage response may be better than a complicated fallback. For a critical journey, however, leaving the behaviour undefined does not remove complexity; it postpones it until the worst possible moment.

Prioritize degraded-mode design where interruption creates material customer harm, revenue loss, safety exposure, regulatory consequences, or a costly manual recovery. Keep the design proportional elsewhere.

Conclusion

Resilience is not only the ability to restore every dependency. It is the ability to preserve the right business promise while the system is incomplete. Define that promise per journey, make uncertainty explicit, constrain the fallback, and test the full recovery cycle. Then an incident becomes execution of an agreed design rather than a live debate about what the system is allowed to do.