The latest articles on DEV Community by Hakan (@omegion). https://dev.to/omegion https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3541342%2Fa8295911-6580-45ca-b39a-0a50abcbdab9.jpeg https://dev.to/omegion en Hakan Wed, 01 Oct 2025 10:01:56 +0000 https://dev.to/omegion/how-i-finally-fixed-rate-limiting-without-writing-a-custom-rate-limiter-3aco https://dev.to/omegion/how-i-finally-fixed-rate-limiting-without-writing-a-custom-rate-limiter-3aco <p>If you’ve ever built an API, you’ve probably had this problem: rate limiting sounds simple, but it’s never simple in practice.</p> <p>At first, you just want to stop someone from hammering your server. But then you realize you need:</p> <ul> <li>Different limits per user or per plan (not everyone pays the same)</li> <li>Fair usage for paying customers</li> <li>A way to block bad API keys without breaking everyone else</li> </ul> <p>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.</p> <h2> Why Most Solutions Don’t Cut It </h2> <p>The usual tools give you a blunt instrument: “100 requests per second” for everyone or maybe a simple per-IP throttle.</p> <p>That’s not enough if you’re running a SaaS API. You want granular control:</p> <ul> <li>Per user ID → User A gets 10 req/s, User B gets 100.</li> <li>Per API key → Different limits for different apps.</li> <li>Per plan → Free vs. Pro vs. Enterprise.</li> </ul> <p>Without that, you’re either over-limiting good customers or under-protecting your infrastructure.</p> <h2> What I Ended Up Building </h2> <p>I wanted three things:</p> <ol> <li>Speed → no big latency hit.</li> <li>Flexibility → define limits on any parameter, not just IPs.</li> <li>Easy integration → drop it in without rewriting the whole stack.</li> </ol> <p>So I built it on top of Cloudflare Workers + KV + DO. The result: checks run in ~25ms, globally distributed.</p> <h2> The Outcome </h2> <p>That project became <strong><a href="https://rately.dev" rel="noopener noreferrer">Rately</a></strong> — a rate limiting service where you can set rules like:</p> <ul> <li>“This user gets 500 calls/day”</li> <li>“This API key gets 50 req/min”</li> <li>“Enterprise plan has no monthly cap”</li> </ul> <p>It’s enterprise-grade, but with simple setup. If you’re curious: rately.dev</p> <h2> Closing </h2> <p>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?</p>