How would you prevent your service from overwhelming an external API when processing many items?

Limit concurrency for external API calls

Design a bounded-concurrency approach for calling an external API safely from .NET code.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I avoid starting one external call per item without a limit. A small in-process workflow can use SemaphoreSlim or Parallel.ForEachAsync with a configured degree of parallelism, while a larger workflow is usually better behind a bounded queue and worker pool. Every call receives cancellation and a timeout, and transient retries stay within a fixed attempt and time budget. The limit starts from the provider's quota and the capacity my service can safely devote to that dependency.

Full answer below

Practice focus

Concurrency limits, rate limits, retries, backoff, SemaphoreSlim, queues, and downstream protection.

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 service can overwhelm a dependency long before it exhausts its own CPU. Bounded concurrency, rate-limit signals, retry budgets, and queues keep downstream pressure predictable when item counts or latency rise.
I avoid starting one external call per item without a limit. A small in-process workflow can use SemaphoreSlim or Parallel.ForEachAsync with a configured degree of parallelism, while a larger workflow is usually better behind a bounded queue and worker pool. Every call receives cancellation and a timeout, and transient retries stay within a fixed attempt and time budget. The limit starts from the provider's quota and the capacity my service can safely devote to that dependency.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, when syncing 5,000 customers to a third-party CRM, I might process only 10 calls at a time and use retry with backoff for transient failures. The trade-off is that the sync takes longer, but it avoids rate-limit errors and protects both systems. I would also respect provider headers like Retry-After and make the limit configurable because provider capacity can change.

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

Firing one HTTP request per item with no limit.
Retrying immediately after rate limits.
Forgetting that local limits do not apply across multiple instances.
Making the limit a magic hard-coded number.
Ignoring partial failure reporting.

How would you prevent your service from overwhelming an external API when processing many items?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement