ORIGINAL TECHNICAL PRACTICE
Bound asynchronous concurrency
You need to process100 URLs with at most five requests active. Explain why Promise.all over100 fetch calls does not impose that limit.
Written for independent practice. The model answer presents one approach; clarify constraints and explain alternatives.
A REASONED APPROACH
Model answer.
Promise.all aggregates promises that have already been created; it does not schedule or cancel the underlying work. A bounded worker pool should claim tasks and start a replacement only after a slot is released.
Work through it
- Keep a shared next-task index and start five asynchronous workers. Each worker awaits its current request before claiming another.
- Store results by original index if output order matters. Choose whether failures are returned per item or stop new scheduling.
- Add per-request timeouts and explicit cancellation with AbortController when required. Confirm that the active-request count remains within five during errors and retries.
Tradeoffs to discuss
- Fail-fast aggregation and complete per-item reporting are different contracts. Retrying immediately inside every worker can still overload a failing service.
Common pitfalls
- Building the fetch promises before passing them to a limiter starts all requests early. Promise rejection alone does not cancel requests already in flight.