Keep a useful service when the provider disappears

Published and revised: October 13, 2026 · Version 1.0.0

Goal and proposed time

In 35–45 minutes, produce a dependency map and a degraded-service decision card. Practice deciding what can still be answered when a provider fails, including when a supposed backup shares the failure or cannot meet the output contract.

Inputs: a complete synthetic incident

Work on paper or with a text-only assistant. No actual provider, account, network request, credential, upload, or paid call is part of the exercise.

The fictional Studio FAQ has three requests: Q1 asks for published opening hours; Q2 asks whether a seat is available now; Q3 requests a note summary. Its response contract requires status, answer, source_id, and observed_at. Availability claims require a live record. No writes are supported.

Use these fixture cards:

• H1: approved static hours, Monday–Friday 09:00–17:00; revision hours-v4; observed_at 2026-10-13T08:00:00Z; expires at 2026-10-14T08:00:00Z. Its owner permits unchanged use before expiry
• A: primary model provider through gateway G; depends on identity service I and approved source store S
• B: proposed backup model provider; a different model, but also through G and I
• C: separate provider through G2; not approved to receive this task's inputs. Supplied sample output is {"text":"The studio is always open"}, with no source or observation time
• Incident: at simulated 12:00Z, G is unavailable. I, S, and the local static-card renderer are healthy. No live seat record can be obtained through the approved route

Work the incident

1. Draw the dependency edges for A and B. Show that both routes cross G. List C separately with authorization and response-compatibility marked unresolved
2. Define the minimum honest service: display valid static hours, disclose unavailable live information, and defer unsupported generation. Set status to degraded, unavailable, or ready; a partial answer cannot be labelled fully ready
3. Fill one row per request: evidence available, blocked dependency, permitted response, withheld claim, and next human decision
4. Simulate two failures through A. For this drill, stop further calls after the second failure and permit at most two later probes, one at a time, only with an operator-supplied recovery card. Record counters on paper. These are chosen rehearsal limits, not production recommendations
5. Inspect C's supplied sample without calling C. Record both problems: the destination lacks approval and its response violates the required contract. Repairing a schema would not authorize transmitting inputs

Worked decision and why

Q1 can return degraded status and the unchanged weekday hours, citing H1 and its observation time while stating that live checks are unavailable. At 12:00Z the card is still valid under its explicit reuse rule. Q2 returns unavailable with answer null because opening hours say nothing about remaining seats. Q3 is deferred; the static renderer cannot summarize a new note.

B does not restore service during a G outage. Selecting C would introduce an unapproved recipient; even an approved route would still need a compatible, source-grounded result. Keep only the supported limited service.

Test cases and expected checks

• G fails, H1 valid: Q1 gets labelled static hours; Q2 and Q3 remain unanswered
• Only A fails and G is healthy: B is technically distinct for this failure, but switching still requires an approved route and tested contract
• H1 is expired: do not present it as current; return unavailable under this fixture's rule
• C is proposed: make no transmission; reject the supplied result's missing fields and unsupported claim
• Recovery card supplies two valid probe responses: permit a proposed controlled return after operator review; one healthy ping alone does not clear the exercise gate

Output and completion check

Return the map, three response rows, call counter, failed-contract record, and recovery conditions. Include a brief evidence-based explanation. Finish when all five expected decisions are documented; stop any run that attempts a real call. No runtime, failover, latency, or reliability benchmark is claimed.

Sources and limits

The scenario and thresholds are original. AWS graceful-degradation guidance supports designing and testing useful behavior during dependency failure. Microsoft's circuit-breaker pattern distinguishes stopping failing requests from limited recovery probes. Neither source validates this fixture or authorizes changing providers.