You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're a downstream consumer of the ClearlyDefined API using the GET /definitions?pattern=&minDescribedScore=80 endpoint to look up component definitions. During normal operation, our service sends 20–100 concurrent GET requests to this endpoint (one per component alias in a single search). We're intermittently seeing HTTP 503 responses on a significant portion of these requests, despite being well within the documented rate limit.
Observed Behavior
When sending 100 concurrent GET requests to [/definitions]:
25–68% of requests return HTTP 503 with body: [{"error":{"code":"503","message":"An error has occurred","innererror":{}}}]
Rate limit headers on the 503 responses confirm budget is untouched:
Impact
This intermittent 503 behavior causes our service to become unavailable when several concurrent searches overlap with a ClearlyDefined degradation window. The pattern search endpoint is the core of our ClearlyDefined integration.
Questions
Is there a known backend capacity issue with the pattern search endpoint under concurrent load?
Is there a recommended concurrency limit we should respect (even though the rate limit allows 2000/min)?
Would batching via [POST /definitions] be more reliable than individual GET /definitions?pattern= calls?
We're a downstream consumer of the ClearlyDefined API using the GET /definitions?pattern=&minDescribedScore=80 endpoint to look up component definitions. During normal operation, our service sends 20–100 concurrent GET requests to this endpoint (one per component alias in a single search). We're intermittently seeing HTTP 503 responses on a significant portion of these requests, despite being well within the documented rate limit.
Observed Behavior
When sending 100 concurrent GET requests to [/definitions]:
25–68% of requests return HTTP 503 with body: [{"error":{"code":"503","message":"An error has occurred","innererror":{}}}]
Rate limit headers on the 503 responses confirm budget is untouched:
Successful requests complete in 0.1–1.1s
Failed requests take 0.5–16s before returning 503 (sometimes up to 45–110s returning 502)
The issue is intermittent - the same batch of requests succeeds 100% during healthy windows and fails 25-68% during degradation windows
Zero HTTP 429 (rate limit) responses observed across hundreds of test requests
Response Details (captured from a 503)
Headers:
Impact
This intermittent 503 behavior causes our service to become unavailable when several concurrent searches overlap with a ClearlyDefined degradation window. The pattern search endpoint is the core of our ClearlyDefined integration.
Questions