Explain What Happens When One Part of the Product Becomes Unavailable

The slide has four clouds and a dotted arrow, and one cloud says availability service. A buyer points at it and asks what happens if that goes down. You have about four seconds, and "it's built to degrade gracefully" is not an answer — it is the name of a category.

Here is an answer that survives a follow-up question. Pick the one customer task your demo actually performs. Name the single supporting service whose absence would change that task. Then walk the task through the gap and sort what you find into four buckets: work that continues, information that is no longer true, actions the product refuses, and things nobody can say yet. Then label each bucket by how you know it.

The four buckets are not a slogan. They are a filing system, and most of the work is refusing to file something in the wrong drawer.

Choose the customer task and the dependency it needs

Start with the task, not the diagram. A task is something a buyer would recognize as their own afternoon: find a class, hold a seat, pay, get a confirmation. "The booking module" is not a task. Neither is "the API layer."

Now find the one dependency that matters to it. The test is narrow and useful: if this service stopped responding right now, which step of that task would the customer notice? Not which services are involved — which step changes. Everything else can stay on the architecture page where it belongs.

Two things need naming before you go further. The version of the product you are describing, because behavior changes between releases. And the person who owns the running system, because you are not the authority on what it does. Ask them a specific question: which of these behaviors is implemented, and what can you show me about it without exposing private systems or customer information?

That phrasing matters. You are not asking whether the system is reliable — a question that produces reassurance. You are asking which behavior exists and what evidence sits behind it. "We designed it to do that" and "we watched it do that" are different sentences, and both are different from "we think it probably would."

AWS's Well-Architected reliability guidance, in a recommendation titled Implement graceful degradation to transform applicable hard dependencies into soft dependencies (REL05-BP01, checked September 2026), frames the aim this way: a lost dependency should reduce service rather than end it, and unfinished transactions and inconsistent state need handling of their own. That is a good mental model for the terrain. It is architecture guidance, not evidence that any particular product behaves that way — including yours. The guidance tells you what to look for. The owner tells you what is there.

Follow the task while that dependency is missing

Now walk the task through the gap. What follows is an invented scenario, worked on paper. Nothing in it has been tested, and no fault has been injected anywhere.

The fictional product is a booking tool. A customer searches a shortlist of appointment slots, chooses one, and submits a reservation. The dependency is an availability provider that answers exactly one question: is this slot still open right now? In the scenario, that provider stops responding.

Four things happen, and they are different from each other.

Browsing continues. The customer can still scroll the shortlist, because the product kept a cached copy. The copy is shown with the time it was cached — "availability as of 09:41" — so the customer knows what they are looking at. This is the genuinely useful part of reduced operation, and it is worth showing on a slide because it is concrete: the customer can still decide what they want.

The information goes stale. A shortlist from 09:41 is a claim about 09:41. Some of those slots will already be gone, and the product no longer has a way to say which. Browsing still works; trusting what you browse does not.

The reservation is refused. The customer picks a slot and presses Reserve. The product cannot confirm the slot is open, so it does not accept the reservation. It says so plainly. There is no success screen, no confirmation email, no slot held on the customer's behalf.

One thing is unknown. A customer who pressed Reserve at 09:41:58, one second before the provider went quiet, is in a genuinely unresolved state. That request may have been written, dropped, or written twice. Nobody knows, and this is the honest center of the example.

Notice the temptation in the third bucket. It is much more comfortable to say the reservation was "queued" — it sounds like the product is holding the customer's place, doing something useful on their behalf. Do not use that word unless three things are true and supported: the request is actually stored somewhere durable, something will actually resubmit it, and the customer has been told it is waiting. If any of those is missing, "queued" is a story about a database write that may never have happened. An action that cannot proceed is allowed to stop, and stopping explicitly is often the kinder outcome. A customer who is told "we can't confirm this slot right now" can try again in ten minutes. A customer who is told their booking is queued may show up on Thursday.

Notice also what is not in the four buckets: the half-finished details sitting in the customer's open form. Whether the product preserves them is a question for the owner, not a thing to assume. The refusal itself writes nothing on the product's side, so the only unfinished work to ask about there is whatever sits in the customer's browser form — and that is a question, not a finding. The request already in flight at 09:41:58 is the separate case: it is product-side work, it may have landed once or twice, and nothing in the refusal story settles what happened to it.

Explain what return of service does not automatically resolve

The provider comes back. This is where most failure explanations quietly cheat, because "recovery" sounds like one event. It is at least two.

In the fictional scenario, refreshing availability and submitting the reservation are separate operations. The product has to re-read live availability before it will accept anything, because the shortlist the customer is looking at is still the 09:41 version. The slot they chose may now be taken. A slot that was open when the customer made their decision is not the same as a slot that is open when the product can act on that decision.

So the return of service does not complete the customer's task. It restores the capability to confirm things. The customer, or the product on their behalf, still has to redo the step that failed. That distinction is worth saying out loud on a slide, because a buyer who hears "it recovers" will picture the booking completing by itself.

Then there is the interrupted request from 09:41:58, and the return of the provider does not answer the question about it. Whether it needs a retry, a confirmation, a lookup, or a human reconciling two records is something only the owner can tell you — and possibly something the owner cannot tell you yet either, because the answer depends on where the write actually lands. Duplicate work and lost work are both live possibilities here. Phrase them as questions. "What happens to a reservation submitted in the seconds before the outage?" is a question an owner can answer or admit they do not know. "No work is lost" is a claim you have just made on their behalf, with nothing behind it.

That said, some recovery questions have easy answers, and you should collect them when you can. Does the refusenik customer get told to try again, or does the product retry for them? Is there a cutoff after which the customer should check their inbox? Is there a place a customer can look to see whether their booking exists? These are small, answerable, and much more useful to a buyer than a promise about data integrity.

Put the evidence status beside each behavior

Now label the buckets. Three labels cover almost everything, and they are not a ranking — they are a statement of where the knowledge came from.

Observed means someone watched it happen, in a test you can name, with conditions you can describe. Documented means the responsible team has written down the intended behavior, or the system's own design records specify it. Proposed means it is what someone thinks should happen.

The labels attach to individual steps, not to a slide. A single sequence can be documented down to step three and proposed from step four onward, and mixing them under one reassuring title is how a presentation turns into a claim nobody can support.

For the fictional booking tool, everything above is proposed. It is a paper walkthrough of an invented product. That is not a weakness of the example; it is the point. Here is roughly what the two versions look like side by side.

The vague slide reads: Booking stays available during availability issues. Customers keep browsing and booking. Everything reconciles when service returns. Three sentences, no step, no time, no source. It also happens to assert that booking continues, which contradicts the scenario it is supposed to describe.

The explicit version is a customer-state sequence, five rows, each with its own evidence line:

That table is more useful than the vague slide for an unglamorous reason: a buyer can point at a row and ask about it. The vague slide gives them nothing to point at, so the conversation drifts toward trust in general, which is a harder thing to win and an easier thing to lose.

A few cautions about the labels, because they are easy to over-claim.

A single observed failure does not describe all outages. A provider that rejects requests quickly and a provider that hangs until a timeout produce very different customer experiences — one gives you an error message in milliseconds, the other strands a spinner for thirty seconds and then does something the customer did not choose. Which one you watched determines which one you can describe. Say which one it was.

A test in a controlled environment with a deliberately broken dependency is real evidence, and it is stronger than a design document. It is also not the same as an outage that happened on its own, at a bad time, with real customer traffic. Both are worth having; neither is the other.

And architecture advice is not evidence about your product. The AWS guidance cited earlier is a general framework for reasoning about degraded operation. It says a lost dependency need not mean a lost product, and that unfinished transactions deserve explicit attention. It says nothing about what your booking tool does on a Tuesday.

Keep the two layers separate in the room. The customer-state sequence goes in the deck. The underlying account — the test conditions, the owner's answers, the parts still open — stays with you for review, so that when someone asks how you know, you have a real answer instead of a fuller diagram.

Where to stop

The best ending for this explanation is not a reassurance. It is a short, specific statement of three things: what the customer loses, what they can still do, and what remains unresolved.

For the fictional booking tool: the customer loses the ability to confirm a slot. They keep the ability to browse a clearly dated shortlist and decide what they want. And what happened to a reservation submitted in the seconds before the provider went quiet is not yet established.

That is a less comfortable slide than a cloud of backup icons. It is also the version that survives the follow-up, because a buyer can hear exactly where your knowledge ends, and it ends in a place that does not threaten them. A truthful blocked action is a better sales position than a continuity story nobody has tested.

If the thing that breaks is your demonstration rather than your product — the projector, the sample data, the laptop — that is a different problem with a different method. One is about the product failing. The other is about the demo failing. They are easy to confuse in a conference room, and confusing them is how a presenter ends up promising graceful degradation for a dead HDMI cable.

Frequently asked questions

How do I explain degraded behavior without saying 'graceful degradation'?

Pick one customer task your demo actually performs, name the single supporting service whose absence would change that task, walk the task through the gap, and sort what you find into four buckets: work that continues, information no longer true, actions the product refuses, and things nobody can say yet. Then label each bucket by how you know it.

What should I say about a reservation submitted just before the outage?

In the invented booking example, a request pressed at 09:41:58 may have been written, dropped, or written twice. Nobody knows, and that is the honest center of the example. Phrase it as a question for the system owner. Do not say 'queued' unless the request is actually stored durably, something will actually resubmit it, and the customer has been told it is waiting.

What does return of service fix?

It restores the capability to confirm things, not the customer's completed task. The product must re-read live availability before accepting anything, because the shortlist the customer is looking at is still the old version. The slot may now be taken, and the customer or product still has to redo the failed step. The interrupted request from before the outage remains a separate owner question.

What evidence labels should accompany each behavior?

Observed means someone watched it happen in a test you can name, with conditions you can describe. Documented means the responsible team or the system's design records specify the intended behavior. Proposed means it is what someone thinks should happen. Labels attach to individual steps, not to a whole slide. In the fictional booking tool example, everything above is proposed.

Does a controlled failure test prove how the product will behave in a real outage?

A controlled test with a deliberately broken dependency is real evidence and is stronger than a design document, but it is not the same as an outage that happened on its own, at a bad time, with real customer traffic. Also distinguish a provider that rejects requests quickly from one that hangs until a timeout; they produce very different customer experiences. The AWS guidance is a general architecture framework, not evidence about any particular product.

Further reading

• Show How an Integration Works Without Calling Every Connection Native — Use when the unavailable part is an integration: it helps trace one exchange through trigger, result, boundary, and the person who owns a stuck request.
• Explain an AI Product’s Data Path in a Buyer Presentation — When behavior depends on where data goes, read this to trace one workflow through processing, storage, and access, and to name what remains unresolved.