Cloudflare offers different rate limiting mechanisms to protect public APIs, such as rules based on IP, routes, or headers. Some users claim these restrictions improve security and reduce resource consumption, while others experience unexpected latency or legitimate blocks. In environments where traffic is variable, what strategy do you recommend to balance protection and availability? Is it preferable to enforce strict limits at the edge and delegate fine-grained control to the backend, or to rely on more flexible policies directly within the application? I'm interested in hearing about experiences and best practices.
Impact of Cloudflare rate limits on public APIs: Benefit or overhead?
👁️ 184 views💬 2 replies❤️ 0 likes
2 Replies
In my recent project of a public static resource API, I started by setting a limit of 100 req/s per IP directly in Cloudflare using a firewall rule. At first, it worked well: it blocked some bots and kept CPU usage low at the origin. But soon I noticed that legitimate users with multiple synchronized devices started getting unexpected 429 errors, especially during traffic spikes. To fix this, I changed my strategy: I kept the rule at the edge only for "burst" (short peaks) – 200 req/s with a 10-second window – and delegated quota control to my backend with an API token that includes a Redis counter. This way, the edge filters massive attacks, but the backend can apply finer logic (e.g., different quotas per subscription plan) without sacrificing the user experience. In my case, combining both layers reduced latency and avoided legitimate blocks, so I recommend using "soft" limits in Cloudflare and leaving detailed throttling to the backend.
In my high-traffic public API project, the best-performing rate-limiting setup was a "soft" limit at the edge (Cloudflare) with fine-grained control delegated to the backend. In Cloudflare, I configured a **Rate Limiting** rule by **IP + path** with generous thresholds (e.g., 200 req/min for the main route) and enabled the **Challenge** option so that clients exceeding the limit would receive a CAPTCHA instead of an outright block. This approach prevents abuse spikes while reducing server load, and legitimate users who temporarily exceed the limit can still access the service after solving the challenge.
On the backend, I implemented a Redis-based rate-limiting middleware that tracks usage by **API token** and **authenticated user**, with much stricter thresholds (e.g., 5 req/sec per token and 1000 req/hour per user). This level allows for differentiated throttling policies based on the customer’s plan or endpoint criticality, without relying solely on the edge. The key is using Cloudflare to filter obvious spikes while keeping business logic and fine-grained prioritization in the application—this keeps latency low and minimizes legitimate blocks.