Deal with MS_MAX_CONCURRENT_REQ by re-trying with exponential back-off?

[dannyvankooten]

there is a limitation on the concurrent requests handled by VoW. There is a maximum number of concurrent requests the system can handle. If the system receives a new request and the maximum number of concurrent requests is reached, the request is rejected. The maximum number of concurrent requests is not linked to a specific IP. It is a global count across all users. In addition, the MAX Concurrent limitations addresses both the VoW overall as well as each Member State separately and for each type of validation request namely, Manual (INT), SOAP (API), REST (API) as well as BATCH. On request though from some National Administrations, we unfortunately cannot disclose the exact level of the thresholds in VoW.

Since we keep running into this issue and it can be circumvented by retrying at increasing intervals, should we handle this from within the library?

[eason4kim-rocket]

Short answer: a few retries inside the library are worth it, but they should not turn MS_MAX_CONCURRENT_REQ into a boolean false.

That fault is a member-state global cap (especially tight for DE), not an invalid VAT number and not an IP-specific limit. Collapsing it into "invalid" rejects real companies whenever the German backend is busy, which is often.

A split that works in production:

1. Library (this package): retry a small number of times with exponential backoff (1s / 2s / 4s) on the transient faults from the WSDL: MS_MAX_CONCURRENT_REQ, GLOBAL_MAX_CONCURRENT_REQ, MS_UNAVAILABLE, SERVICE_UNAVAILABLE, TIMEOUT. After that, return a distinct "unavailable" result or throw a typed exception. Do not retry INVALID_INPUT or a confirmed invalid number.
2. Caller: treat VIES as three-valued — valid / invalid / unknown. Only invalid should fail checkout or onboarding. Queue unknown and retry in 30–60s. A long retry loop inside a web request just hangs the user.

Caching a successful valid result for 24h (keyed on country + number) also cuts a lot of repeat hits without changing the meaning of the check.

So: yes to bounded backoff in the library, as long as exhausted retries stay distinguishable from "this VAT number is not allocated".