Concept questionMedium~7 minResilience & Dependency Failures Essentials / 5 of 16

Interview question

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production every critical dependency path would have a documented failure mode, fallback owner, maximum stale age, security classification, and recovery procedure. Feature flags or kill switches can disable optional calls, while dashboards show fallback rate, stale age, partial responses, queued operations, and downstream recovery. I would test fallback data missing, fallback storage failing, conflicting partial results, prolonged outage, and gradual restoration. The strongest design keeps the normal and degraded contracts simple enough that clients can handle both without guessing.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

The degraded response is indistinguishable from complete fresh data.
Nobody owns the maximum stale age.
Clients cannot tell whether a timed-out action happened.
Recovery creates an uncontrolled backlog spike.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Which data would you serve stale?
When should an API fail closed?
How would a client represent partial data?
What happens to queued work after recovery?

Continue the section

Next in Resilience & Dependency Failures Essentials: Health Checks

Step 6 of 16

Design health checks for readiness, liveness, and startup

Opening drill

Concept questionMedium~7 minResilience & Dependency Failures Essentials / 5 of 16

Interview question

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

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production every critical dependency path would have a documented failure mode, fallback owner, maximum stale age, security classification, and recovery procedure. Feature flags or kill switches can disable optional calls, while dashboards show fallback rate, stale age, partial responses, queued operations, and downstream recovery. I would test fallback data missing, fallback storage failing, conflicting partial results, prolonged outage, and gradual restoration. The strongest design keeps the normal and degraded contracts simple enough that clients can handle both without guessing.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

The degraded response is indistinguishable from complete fresh data.
Nobody owns the maximum stale age.
Clients cannot tell whether a timed-out action happened.
Recovery creates an uncontrolled backlog spike.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Which data would you serve stale?
When should an API fail closed?
How would a client represent partial data?
What happens to queued work after recovery?

Continue the section

Next in Resilience & Dependency Failures Essentials: Health Checks

Step 6 of 16

Design health checks for readiness, liveness, and startup

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

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