Debugging scenarioHard~12 min

Interview question

An external dependency is timing out and causing your ASP.NET Core API to fail. How do you handle it?

Handle downstream dependency timeouts in an API

Investigate and mitigate API failures caused by a slow or failing downstream dependency.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Suppose an order POST times out while calling a payment provider, and the provider log shows the request reached it but our API received no response. I treat the payment outcome as unknown, not failed. I stop automatic retries with new identities, preserve the provider request id and local operation id, and return or expose a pending state while the service queries or reconciles the authoritative provider outcome.

Full answer below

Practice focus

dependency isolation, timeout strategy, retry judgment, graceful degradation, observability, and incident mitigation

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
Investigate and mitigate API failures caused by a slow or failing downstream dependency. It matters in real backend work because the team needs observability, ownership, and rollback room to recover without guessing. The practical angle is dependency isolation, timeout strategy, retry judgment, graceful degradation, observability, and incident mitigation, tied to a concrete production decision.
Suppose an order POST times out while calling a payment provider, and the provider log shows the request reached it but our API received no response. I treat the payment outcome as unknown, not failed. I stop automatic retries with new identities, preserve the provider request id and local operation id, and return or expose a pending state while the service queries or reconciles the authoritative provider outcome.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The same logical order reuses one idempotency key at our API and the provider. If reconciliation finds the payment, the local state advances idempotently and emits any follow-up through the outbox. If the provider proves it did not occur, a controlled retry can reuse that identity. A caller cancellation, our timeout, a provider rejection, and an unknown write outcome remain distinct states; flattening them into one retryable exception is how duplicate charges appear.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
Containment limits new payment attempts while allowing known-safe reads and status checks. I monitor pending age, reconciliation results, provider idempotency responses, duplicate attempts, and the exact timeout stage. Recovery tests force the lost-response window after provider success and prove that a retry returns the same logical outcome. The general latency incident owns capacity, degradation, and dependency recovery; this follow-up exists because an ambiguous external write changes the correctness decision.

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

Increasing timeouts blindly
Retrying non-idempotent calls
Letting one dependency consume all resources
Returning vague 500s
Ignoring optional vs critical dependencies

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Does not ask whether the operation is idempotent
Treats retries as automatically safe
Cannot discuss degradation
Ignores blast radius

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.

When would you retry?
When would you fail fast?
How do you avoid retry storms?
What would you monitor?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Abstraction vs encapsulationConcept question / Easy / ~5 minContinue Access modifiersConcept question / Easy / ~5 minContinue ActionResult vs Typed ResultsComparison question / Medium / ~7 minContinue

Practice route

Read core answer Review checklist Follow-up prompts Track progress

Finished this drill?

Practice freely. Sign in only when you want to save completion, confidence, notes, or bookmarks.

New to Aporeon? Create account

Drill details

Share the question with a concise Core-answer excerpt and invite other developers to add their perspective.

Was this drill useful?

Help improve the interview library.

Found this answer useful?

Say thanks with a standalone, one-time $5 contribution. No account required.

No subscription or perks.Choose another amount

Human editorial direction

Aporeon is shaped by Aleksandar Tomovski, a software developer with experience on both sides of technical interviews. Content is reviewed for accuracy, natural spoken delivery, useful depth, and honest trade-offs.

About the creator Editorial standards

Opening drill

Debugging scenarioHard~12 min

Interview question

An external dependency is timing out and causing your ASP.NET Core API to fail. How do you handle it?

Handle downstream dependency timeouts in an API

Investigate and mitigate API failures caused by a slow or failing downstream dependency.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

dependency isolation, timeout strategy, retry judgment, graceful degradation, observability, and incident mitigation

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
Investigate and mitigate API failures caused by a slow or failing downstream dependency. It matters in real backend work because the team needs observability, ownership, and rollback room to recover without guessing. The practical angle is dependency isolation, timeout strategy, retry judgment, graceful degradation, observability, and incident mitigation, tied to a concrete production decision.
Suppose an order POST times out while calling a payment provider, and the provider log shows the request reached it but our API received no response. I treat the payment outcome as unknown, not failed. I stop automatic retries with new identities, preserve the provider request id and local operation id, and return or expose a pending state while the service queries or reconciles the authoritative provider outcome.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The same logical order reuses one idempotency key at our API and the provider. If reconciliation finds the payment, the local state advances idempotently and emits any follow-up through the outbox. If the provider proves it did not occur, a controlled retry can reuse that identity. A caller cancellation, our timeout, a provider rejection, and an unknown write outcome remain distinct states; flattening them into one retryable exception is how duplicate charges appear.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
Containment limits new payment attempts while allowing known-safe reads and status checks. I monitor pending age, reconciliation results, provider idempotency responses, duplicate attempts, and the exact timeout stage. Recovery tests force the lost-response window after provider success and prove that a retry returns the same logical outcome. The general latency incident owns capacity, degradation, and dependency recovery; this follow-up exists because an ambiguous external write changes the correctness decision.

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

Increasing timeouts blindly
Retrying non-idempotent calls
Letting one dependency consume all resources
Returning vague 500s
Ignoring optional vs critical dependencies

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Does not ask whether the operation is idempotent
Treats retries as automatically safe
Cannot discuss degradation
Ignores blast radius

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.

When would you retry?
When would you fail fast?
How do you avoid retry storms?
What would you monitor?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

An external dependency is timing out and causing your ASP.NET Core API to fail. How do you handle it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

An external dependency is timing out and causing your ASP.NET Core API to fail. How do you handle it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice