Good afternoon,
We’ve been noticing a high frequency of 429 Too Many Requests responses to FHIR PDS requests in INT environment, we’ve been accredited for a while now and have only noticed this fairly recently.
HTTP 429 Too Many Requests: This API is currently receiving a high volume of requests and is being rate limited. Please see: https://digital.nhs.uk/developer/guides-and-documentation/reference-guide#rate-limits for more details.
My understanding is that in INT capacity is pooled, while in live its on a per application basis, is this correct?
Is this likely to be an issue we see in int but not in live?
Is there any recommended approach to dealing with this error?
Thanks,
Liam
Hi,
Thank you for highlighting this.
Indeed, the personal demographics service running in INT is constrained by an overall rate limit of 20 TPS.
This environment is intended for functional testing, verifying if the integration with our service works as expected, by no means stress or performance testing.
Depending on the type of request and the use case, a consumer can choose to re-try a failed request (e.g. 429 returned), using an incremental back-off policy.
Please let us know if any further information would be required.
Also, if you feel that the official documentation could be improved, please highlight the areas that you are most interested in so we can enhance them.
1 Like
Hi Claudia,
Thanks for the prompt reply.
So where we have non-user present lookups (i.e. some stuff related to ERS) we’ve implemented incremental back off, in the case of user present events we alert the user with advice to wait and trigger the lookup later and allow progress without the PDS lookup where possible.
I think our concern is more about this happening with increasing frequency impacting our UAT testing both internally and acceptance testing with trusts.
Currently there’s a sandpit environment environment which returns a limited number of responses and isn’t really suitable for testing most use cases and INT as the only environments we can really deploy against to test any feature. We do have a home made dummy/sandpit we can do some testing against (all our automation and load should be going against this) but its limited and as its just returning exactly what we expect not really suitable for a lot of testing.
As we develop more API interactions we find more and more things where we need PDS interactivity as part of work flows (GPConnect, EPS, ERS, Flags API etc), some (ERS for example, which we rate limit) potentially reflecting large numbers of lookups which will need to happening against INT currently. The scope of the SCAL requirements (i.e. we need to sync at various points) means PDS is pretty integral to various work flows and any functional testing like live needs to go against a PDS service that functions. This means I’m pretty sure our usage is growing at a reasonable rate as we roll these features out into our conformance environments internally and with trusts and I suspect the same is true of other providers.
As the request count is pooled it means we hit issues are presumably outside our control that effect our testing and that of trusts.
Not sure if it would be possible to look at if there’s anything thats specifically eating up a lot of the requests or if increasing usage may justify individual limits or a higher overall limit?
Thanks,
Liam
Hi,
Thank you for all the information provided. We are aware of this issue and would be eager to address it, however I would advise to please raise it with the service desk so that we can prioritise it against our existing backlog and track it more formally ( You can contact the NHS national service desk via email ssd.nationalservicedesk@nhs.net, phone 0300 303 5035 or via Customer Service Portal - Customer Support (service-now.com). )