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

Interview question

How would you set timeouts across an API request and its downstream dependencies?

Set timeout budgets across downstream dependencies

Sets bounded timeout and deadline policies across callers, APIs, databases, and external services without hiding unknown outcomes.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would start with the response-time objective for the whole user request, then give each dependency a smaller timeout inside that budget. The API must leave time to map the result and return it, so a downstream call cannot use the caller's entire deadline. I would configure the HTTP, database, or SDK timeout explicitly and pass cancellation through supported operations. A timeout means the result was not observed in time; it does not prove that a remote side effect did not happen.

Full answer below

Practice focus

End-to-end deadlines, per-dependency timeouts, cancellation propagation, unknown outcomes, and latency-budget ownership.

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
A timeout protects more than response time. It limits how long one dependency can hold request capacity, connections, and work that the caller may no longer need.
I would start with the response-time objective for the whole user request, then give each dependency a smaller timeout inside that budget. The API must leave time to map the result and return it, so a downstream call cannot use the caller's entire deadline. I would configure the HTTP, database, or SDK timeout explicitly and pass cancellation through supported operations. A timeout means the result was not observed in time; it does not prove that a remote side effect did not happen.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For a request that calls several services, I would budget the critical path rather than assigning the same timeout everywhere. Sequential calls consume the budget one after another, while parallel calls share elapsed time but increase downstream concurrency. I would distinguish the caller disconnecting from my dependency deadline because they have different telemetry and recovery. Read calls may be abandoned safely, but a timed-out payment or write has an unknown outcome and needs an idempotency key, durable operation status, or reconciliation before any retry.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would propagate an absolute deadline or remaining budget where protocols allow it, while still enforcing a local maximum at every hop. Proxy, server, client, database, and queue visibility timeouts must agree; an outer layer expiring first can leave hidden work running after the user has received an error. Timeout values come from latency distributions and product objectives, not round numbers copied between services. I would track timeout rate, canceled work, late completions, connection-pool pressure, and remaining budget by dependency, then test slow, hung, and ambiguous side-effect outcomes.

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

Giving every dependency the full request timeout.
Treating a timeout as proof that no side effect occurred.
Configuring only the outer HTTP timeout.
Retrying before classifying the operation and outcome.
Logging caller cancellation and dependency timeout as the same event.

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

Details

External calls can wait without a bound.
A timed-out write is immediately repeated with no idempotency.
Inner work continues after every outer deadline.
Timeout values have no owner, metric, or product objective.

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.

How would you budget three sequential dependency calls?
What changes for a payment request?
Should a caller disconnect cancel a committed operation?
How do proxy and database timeouts interact?

Continue the section

Next in Resilience & Dependency Failures Essentials: Safe Retries

Step 2 of 16

Retry transient dependency failures without causing a retry storm

Opening drill

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

Interview question

How would you set timeouts across an API request and its downstream dependencies?

Set timeout budgets across downstream dependencies

Sets bounded timeout and deadline policies across callers, APIs, databases, and external services without hiding unknown outcomes.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

End-to-end deadlines, per-dependency timeouts, cancellation propagation, unknown outcomes, and latency-budget ownership.

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
A timeout protects more than response time. It limits how long one dependency can hold request capacity, connections, and work that the caller may no longer need.
I would start with the response-time objective for the whole user request, then give each dependency a smaller timeout inside that budget. The API must leave time to map the result and return it, so a downstream call cannot use the caller's entire deadline. I would configure the HTTP, database, or SDK timeout explicitly and pass cancellation through supported operations. A timeout means the result was not observed in time; it does not prove that a remote side effect did not happen.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For a request that calls several services, I would budget the critical path rather than assigning the same timeout everywhere. Sequential calls consume the budget one after another, while parallel calls share elapsed time but increase downstream concurrency. I would distinguish the caller disconnecting from my dependency deadline because they have different telemetry and recovery. Read calls may be abandoned safely, but a timed-out payment or write has an unknown outcome and needs an idempotency key, durable operation status, or reconciliation before any retry.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would propagate an absolute deadline or remaining budget where protocols allow it, while still enforcing a local maximum at every hop. Proxy, server, client, database, and queue visibility timeouts must agree; an outer layer expiring first can leave hidden work running after the user has received an error. Timeout values come from latency distributions and product objectives, not round numbers copied between services. I would track timeout rate, canceled work, late completions, connection-pool pressure, and remaining budget by dependency, then test slow, hung, and ambiguous side-effect outcomes.

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

Giving every dependency the full request timeout.
Treating a timeout as proof that no side effect occurred.
Configuring only the outer HTTP timeout.
Retrying before classifying the operation and outcome.
Logging caller cancellation and dependency timeout as the same event.

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

Details

External calls can wait without a bound.
A timed-out write is immediately repeated with no idempotency.
Inner work continues after every outer deadline.
Timeout values have no owner, metric, or product objective.

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.

How would you budget three sequential dependency calls?
What changes for a payment request?
Should a caller disconnect cancel a committed operation?
How do proxy and database timeouts interact?

Continue the section

Next in Resilience & Dependency Failures Essentials: Safe Retries

Step 2 of 16

Retry transient dependency failures without causing a retry storm

How would you set timeouts across an API request and its downstream dependencies?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How would you set timeouts across an API request and its downstream dependencies?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section