How would you stop one slow dependency or tenant from consuming all of an API's capacity?

Isolate dependency failures with bulkheads and bounded concurrency

Uses per-dependency concurrency limits, queues, pools, and workload partitions to stop one failing path from exhausting the whole API.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would put a concurrency limit around calls to the risky dependency and keep any waiting queue bounded. When the limit and queue are full, new work should fail quickly, be delayed durably, or use a defined fallback instead of waiting without bound. The limit protects request capacity and the downstream service. I would also partition work where necessary, for example per dependency, endpoint class, tenant tier, or background workload, so one hot path cannot starve unrelated critical traffic.

Full answer below

Practice focus

Bulkhead isolation, bounded concurrency, queue limits, fairness, resource pools, rejection behavior, and saturation telemetry.

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
Bulkhead isolation reserves failure boundaries inside a service so one slow provider, expensive feature, or noisy tenant cannot consume every shared resource.
I would put a concurrency limit around calls to the risky dependency and keep any waiting queue bounded. When the limit and queue are full, new work should fail quickly, be delayed durably, or use a defined fallback instead of waiting without bound. The limit protects request capacity and the downstream service. I would also partition work where necessary, for example per dependency, endpoint class, tenant tier, or background workload, so one hot path cannot starve unrelated critical traffic.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The isolation boundary should match the constrained resource. A semaphore around HTTP calls can protect provider concurrency, but it does not fix a shared database connection pool or an unbounded in-memory queue. Critical and optional traffic may need separate budgets, while fairness prevents one tenant from holding every permit. Limits should account for expected latency and downstream capacity; a queue that is much larger than useful throughput only converts immediate rejection into later timeout and memory pressure.

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

Using an unbounded queue in front of the concurrency limit.
Sharing one pool across critical and optional work.
Raising concurrency when the downstream system is already saturated.
Ignoring cancellation while callers wait for a permit.
Applying an HTTP semaphore to a database-pool problem.

How would you stop one slow dependency or tenant from consuming all of an API's capacity?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Technologies

Tech stacks

Skill areas

Suggest an improvement