A read-then-write counter on an eventually consistent store is not a rate limit
Cloudflare KV, and most edge key-value stores, take up to about 60 seconds to propagate a write. A limiter that reads the count, compares, then writes the count back has a race the width of that window. Two hundred requests in the same second all read zero and all pass. The green "rate limited" badge is true only for a polite visitor.
Where it bit
The blinkz-site capture worker. Five per hour, implemented as get, compare, put on KV. The README calls the real limit, a zone WAF rule, "planned." Same shape as the rate-limit-on-the-button mistake: the limit lives on the button, not on the server. Ours lives on the server and still does not hold.
The practice
Limits need an atomic counter: a Durable Object, Redis INCR with expiry, or the platform's own rate-limiting rule at the edge. Coarse KV limits are fine as a second layer, never the only one.
Check it
seq 1 50 | xargs -P 50 -I{} curl -s -o /dev/null -w "%{http_code}\n" -X POST STAGING/api/subscribe \
-H "Content-Type: application/json" -H "Origin: https://blinkz.ai" \
-d '{"email":"x{}@example.com","source":"teardown","website":""}' | sort | uniq -cGet this check as a script you can run tonight
What to do with this
If you run a business on something AI built and the checks came back with more than you expected, that is worth a conversation.
We do a free 30-minute Health Check for service businesses that want to know exactly where their biggest leaks are. No slide deck. No pitch. We ask questions, find the gaps, and tell you what we see. If there is no obvious fix, we will tell you that too.
Blinkz finds what is broken in how a business runs, then fixes it. AI only where it earns its place.