Architecture scenarioMedium~10 minParallel Workloads / 5 of 12

Interview question

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I treat the limit as a dependency-protection boundary. A SemaphoreSlim controls one process only, so multiple replicas may need queue-level consumer limits, partitioned scheduling, or a distributed rate limiter to respect a global quota. I combine concurrency limits with Retry-After handling, jittered backoff, idempotency for retried writes, and load shedding when the backlog exceeds a useful age. Metrics cover in-flight calls, queue depth and age, rate-limit responses, retry amplification, latency, and completed throughput. Those signals let the limit change deliberately without turning dependency recovery into another traffic spike.

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.

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

Details

A weak answer only says 'use Task.WhenAll'. I want to hear how the candidate protects the dependency and handles rate limits.

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 this change with five service replicas?
What retry strategy would you use?
How do you handle Retry-After headers?
When would you move this work to a queue?

Continue the section

Next in Parallel Workloads: BackgroundService Shutdown

Step 6 of 12

Graceful shutdown in BackgroundService

Opening drill

Architecture scenarioMedium~10 minParallel Workloads / 5 of 12

Interview question

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

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I treat the limit as a dependency-protection boundary. A SemaphoreSlim controls one process only, so multiple replicas may need queue-level consumer limits, partitioned scheduling, or a distributed rate limiter to respect a global quota. I combine concurrency limits with Retry-After handling, jittered backoff, idempotency for retried writes, and load shedding when the backlog exceeds a useful age. Metrics cover in-flight calls, queue depth and age, rate-limit responses, retry amplification, latency, and completed throughput. Those signals let the limit change deliberately without turning dependency recovery into another traffic spike.

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.

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

Details

A weak answer only says 'use Task.WhenAll'. I want to hear how the candidate protects the dependency and handles rate limits.

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 this change with five service replicas?
What retry strategy would you use?
How do you handle Retry-After headers?
When would you move this work to a queue?

Continue the section

Next in Parallel Workloads: BackgroundService Shutdown

Step 6 of 12

Graceful shutdown in BackgroundService

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

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