DDoS mitigation

Denial-of-service traffic is filtered before it reaches the origin. It is on by default for every tenant, there is nothing to enable, and it costs nothing extra — there are no tiers on the platform, so this is not a feature you can be on the wrong side of.

This page is deliberately specific about what the protection is and where it applies, because "always-on DDoS protection" is a phrase that means very little on its own.

Where it happens

Filtering happens at the points of presence, for the hostnames a point of presence fronts — the domains you have pointed at the edge.

• Non-HTTP traffic never reaches a point of presence. A packet filter in front of each node accepts HTTP and HTTPS and drops the rest, so traffic aimed at other ports is discarded before it costs anything.
• HTTP-layer floods are handled at the point of presence. Each client is rate-limited per URL, and a client producing an abusive request pattern is blocked automatically for a period rather than being served and counted. The same machine runs the WAF ruleset, so a flood built out of malicious requests is caught on both counts.
• Attack traffic is split across four locations. Because Geo-DNS resolves each region to its own point of presence, a distributed attack lands on whichever nodes its sources resolve to rather than concentrating on one machine.
• What survives all of that hits a cache, not the origin. A flood aimed at a cacheable URL is answered from the point of presence.

What it does not cover

Stating this plainly is more useful than a reassurance:

• api.revenexx.com is not fronted by a point of presence. API traffic is answered by the origin, and its protection is the per-tenant rate limit — 100 requests per second sustained, 200 burst — not PoP-level filtering.
• There is no published absorption capacity, and no SLA for one. The protection above is real and handles the traffic that arrives at a normal commerce platform. It is not a guarantee against an arbitrarily large targeted campaign. If you have reason to expect one — a launch, a known dispute, a public campaign — tell us in advance so it can be watched rather than discovered.
• Nothing here protects you from your own traffic. The most common cause of a storefront falling over is an uncached page under legitimate load, or an integration retrying without backoff. Both look like an attack and neither is one. See Caching and Retries & idempotency.

If legitimate traffic is being blocked

Rate limiting and automatic blocking are tuned to leave normal browsing and normal integrations alone, but a client that genuinely needs to make a burst of requests against one URL can trip them. Symptoms are 429 responses, or requests from one source address failing while others succeed.

Quote the X-Request-ID from a failed response — it makes the request traceable — and contact us with the source address and the URL. An exception can be made for a specific integration.

Related

• WAF — the request filtering that runs on the same machines
• Rate limits — the per-tenant API budget and how to handle 429
• Edge network — the four points of presence and how traffic reaches them