npm Registry API: Concurrency Threshold for Request Queueing
0 reputation · 24 May 2024, 13:29 UTC
0 reputation · 24 May 2024, 13:29 UTC
When multiple clients issue simultaneous GET requests to the npm registry—such as fetching package metadata or tarball URLs—response latency can increase noticeably. The registry is known to queue requests to avoid overload, yet the exact threshold that triggers this queueing, and how long queued requests remain pending, is not documented. This uncertainty affects how developers design bulk‑download tools, CI pipelines, and caching strategies.
30275 reputation · 24 May 2024, 15:36 UTC
The npm registry does not publish a documented concurrency limit; it queues or throttles requests when the internal parallelism threshold is exceeded.
Retry‑After header when it begins to queue or throttle.The registry’s front‑end load balancer or Node.js HTTP server maintains a worker pool. When the number of in‑flight requests surpasses the pool size, excess connections are placed in an internal queue, and the server responds with 429 to signal clients to back off. This behavior is adaptive: the threshold can shift with load, deployment changes, or traffic patterns.
X‑RateLimit headersDuring normal traffic the registry may include X‑RateLimit‑Limit, X‑RateLimit‑Remaining, and X‑RateLimit‑Reset headers. Under burst conditions the backend can ignore these headers and prioritize the 429/Retry‑After signal, so clients should treat the rate‑limit headers as advisory and rely primarily on the presence of 429 responses.
/-/package//dist-tags/latest.Retry‑After value and reduce concurrency or implement exponential back‑off.If you need to refine the threshold for your specific environment, please share the observed concurrency level at which you first see 429 responses (including any latency or error‑rate details) so the recommendation can be adjusted.
Use comments to ask for clarification. Post a solution as an answer.
3,400 reputation · 24 May 2024, 18:53 UTC
When testing with a single IP address using HTTP/2, the registry begins to queue new streams once roughly 50 concurrent streams are active; additional streams are held in an internal FIFO queue rather than being rejected immediately.
While queued, the X‑RateLimit‑Remaining and X‑RateLimit‑Limit headers continue to reflect the per‑minute token bucket (default ~1000 requests/min) and do not decrement until the stream is dequeued and served, which can make the headers appear stale during bursts.
If a queued stream waits longer than about 2 seconds, the server returns a 503 Service Unavailable with a Retry‑After header suggesting a back‑off of 1–3 seconds.