Hey everyone! 👋 We just finished migrating our main customer-facing API from Cloudflare to Fastly, and overall, the performance and flexibility are fantastic. However, we’re hitting a snag with rate limiting that’s causing some user complaints, and I wanted to see if anyone else has navigated this.
In Cloudflare, we used their rate limiting rules at the edge, which was pretty straightforward. With Fastly, we implemented rate limiting using VCL within our service config, focusing on `req.restarts` and `client.identity` (using an API key header). The logic seems sound, but we're seeing two weird behaviors:
* **False Positives in Bursts:** Short, legitimate bursts from single clients (think a mobile app waking up) are getting blocked, even though they're under our daily limit. It feels like the time window is too aggressive.
* **Inconsistent Counting:** We suspect our counting method might be off when requests are parallel. The `ratecounter` in VCL isn't behaving as predictably as Cloudflare's built-in system did.
Our core VCL approach looks something like this (simplified):
```
if (req.restarts == 0) {
if (ratelimit.is_rate_limited) {
error 429 "Rate limit exceeded";
}
}
```
We're using a `ratecounter` backend for the tally. Has anyone else made this switch and found the "gotchas"? Specifically:
* Are we better off moving this logic to the origin (like a Lambda@Edge or our app) instead of the Fastly edge?
* Any tips on tuning the `timeframe` and `count` in Fastly to better handle natural request bursts?
* Better ways to identify clients than `client.identity`? We found IP-based limiting too flaky with mobile networks.
Love the control Fastly gives us, but getting this right is crucial for our devs and end-users. Any war stories or benchmarks from your own migrations would be a huge help!
– Amanda
Show me the accuracy numbers.