A dependency is unavailable. How do you decide whether the API should fall back, return partial data, queue work, or fail?

Design honest fallback and degraded API responses

Chooses safe cached, partial, pending, read-only, or unavailable behavior and makes degraded state explicit to clients and operators.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would classify the dependency by what can go wrong if its result is missing or stale. Optional recommendations can be omitted, and some reference data can use a bounded cached value. A long-running write can be durably accepted and reported as pending. Authorization, payment state, inventory reservation, and other critical decisions may need to fail closed when the source of truth cannot be checked. The response should not silently look complete when data is stale or partial.

Full answer below

Practice focus

Fallback safety, stale and partial data, pending workflows, fail-open versus fail-closed decisions, and client-visible degradation.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Degraded behavior is a product contract, not an exception handler. The fallback must preserve safety while telling clients what is stale, missing, pending, or unavailable.
I would classify the dependency by what can go wrong if its result is missing or stale. Optional recommendations can be omitted, and some reference data can use a bounded cached value. A long-running write can be durably accepted and reported as pending. Authorization, payment state, inventory reservation, and other critical decisions may need to fail closed when the source of truth cannot be checked. The response should not silently look complete when data is stale or partial.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The API contract should identify degraded state in a stable way, such as explicit freshness metadata, omitted optional fields, a partial-result status, or an operation resource for queued work. Clients need to know whether retry is useful and whether the original action may already have happened. I would avoid a fallback that sends uncontrolled traffic to another shared dependency or serves data beyond its safe age. Recovery also needs rules so cached and queued work does not flood the system when the provider returns.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Returning stale data without freshness information.
Failing open for authorization or money decisions.
Calling another dependency with no capacity limit as the fallback.
Queuing work without durable status or idempotency.
Restoring full traffic instantly after a long outage.

A dependency is unavailable. How do you decide whether the API should fall back, return partial data, queue work, or fail?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Technologies

Tech stacks

Skill areas

Suggest an improvement