We tested our rate limiter with 33 requests. Zero were blocked.
A limiter that exists is not a limiter that works. What we found when we tested ours, how we fixed it, and why we publish it.
- A safeguard in the code can still do nothing. Test it by pushing past the limit.
- Memory inside a short-lived function is not shared state.
- We found this before real users, on a demo clinic. It is fixed, not yet measured under load.
- We list our own faults because it is the honest answer to 'what did your last audit find?'
Quick answer
On a clinic-queue platform we built, the first rate limiter kept its count in memory and blocked nothing: 13 requests in sequence and 20 in parallel, none refused. We moved the counter into the database and a live test then showed requests being refused. We found it because we tested the limiter itself.
What happened
We built a rate limiter to stop one caller flooding the platform. It was in the code. It looked right. So we tested it: 13 requests one after another, then 20 at once. Zero were blocked.
Why
The count lived in the memory of the function handling each request. Functions like these don’t reliably share memory between requests, so every request saw a fresh count. The limit was never reached because nothing remembered the last request.
The fix
We moved the counter into the database, where every request sees the same number. We then repeated the test against the live setup. Requests were refused once the limit was reached.
What this does and doesn’t show
Built and tested on a demo clinic ahead of launch. The fix works in that test. We have not measured it under real load, and we don’t publish the limit or settings.
It shows that we test safeguards, not only features, and that testing found a defect that reading the code did not. It does not show that the platform is secure. A rate limiter is one control among many, and we do not use “secure” as a blanket claim.
Why we publish this
When you vet a vendor, one good question is: what did your last audit find, and what is still open? This is part of our answer. The full checklist is here, and here is how to test before real users arrive.
The numbers come from our own test notes for the clinic-queue platform and are tracked in our claim ledger. No figure comes from a third party.
More by GarunaCDX
Get GarunaCDX news in your inbox.
Launches, new case studies and the industry shifts we are watching — once a month.
