Here is a question we could not answer well a year ago: what really happens with the hidden cost of retries during a flood? We can answer it now.
Protecting the origin
None of this matters if the attacker can reach your origin directly. Historical DNS records, certificate transparency logs and misconfigured subdomains leak origin addresses all the time.
Allow-list the edge ranges, enable authenticated origin pulls and treat any origin IP that ever appeared in public DNS as burned.
Latency budget
Our budget for the whole filtering pipeline is one millisecond at the 99th percentile. Anything that cannot be decided within that budget runs asynchronously and influences the next request from the same client, not the current one.
That constraint shapes everything: data structures, where state lives and which signals we are willing to compute inline.
Why per-route baselines matter
A thousand requests per second to your homepage is Tuesday. A thousand requests per second to your password-reset endpoint is an attack. Global rate limits cannot tell the difference; per-route baselines can.
We learn the normal shape of traffic per route and per hour of the week, so a surge on a sensitive endpoint raises the risk score long before it approaches a global threshold.
Measuring success
We track three numbers for every incident: time to mitigation, the share of attack traffic that reached the origin, and the share of legitimate traffic that was challenged. The first should be under a second, the second under 0.1% and the third under 1%.
Those numbers go into every incident report, and they are the same numbers we are measured against in our SLA.
Compliance is a side effect
Regulators increasingly ask for evidence of resilience, not just promises. An incident timeline with start, peak, vectors and impact is exactly the evidence DORA and NIS2 ask for — and it falls out of good observability for free.
We export incident reports in formats auditors can file without anyone rewriting them.
{ "match": { "path": "/api/v1/checkout", "risk": ">= 62" }, "action": "challenge" }
The full incident data behind this post is available to customers in the dashboard under Reports.
This matches what we see in iGaming around big matches.
Nice to read a vendor blog that admits what went wrong.
Good question. We will cover that in a follow-up post.
The point about origin IPs leaking through certificate transparency logs is underrated.
Great write-up. We saw almost the same pattern on our login endpoint last month.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
The billing model is what got our finance team on board, honestly.