How I Finally Fixed Rate Limiting Without Writing a Custom Rate Limiter

If you’ve ever built an API, you’ve probably had this problem: rate limiting sounds simple, but it’s never simple in practice.

At first, you just want to stop someone from hammering your server. But then you realize you need:

• Different limits per user or per plan (not everyone pays the same)
• Fair usage for paying customers
• A way to block bad API keys without breaking everyone else

I’ve been through this more times than I’d like to admit. Each time I hacked together some middleware or a Redis script. It worked… kind of. But it was messy, fragile, and slow.

Why Most Solutions Don’t Cut It

The usual tools give you a blunt instrument: “100 requests per second” for everyone or maybe a simple per-IP throttle.

That’s not enough if you’re running a SaaS API. You want granular control:

• Per user ID → User A gets 10 req/s, User B gets 100.
• Per API key → Different limits for different apps.
• Per plan → Free vs. Pro vs. Enterprise.

Without that, you’re either over-limiting good customers or under-protecting your infrastructure.

What I Ended Up Building

I wanted three things:

1. Speed → no big latency hit.
2. Flexibility → define limits on any parameter, not just IPs.
3. Easy integration → drop it in without rewriting the whole stack.

So I built it on top of Cloudflare Workers + KV + DO. The result: checks run in ~25ms, globally distributed.

The Outcome

That project became Rately — a rate limiting service where you can set rules like:

• “This user gets 500 calls/day”
• “This API key gets 50 req/min”
• “Enterprise plan has no monthly cap”

It’s enterprise-grade, but with simple setup. If you’re curious: rately.dev

Closing

I know I’m not the only one who’s fought with this. How are you handling rate limiting in your project right now? Did you roll your own, or are you using a service?