I'm trying to figure out how to implement different rate limits for users based on their subscription plans for an application in 2025. Here's what I'm thinking:
* Free users get 10 requests per month.
* Tier 1 users get 30 requests per month.
* Pro users get 100 requests per month.
* The limits reset on the 1st of each month.
* I want to enforce these limits before any requests hit my backend.
What's the best way to do this today? Should I store counters in Redis, use Cloudflare Workers KV or Durable Objects, or handle it in my backend database? Or should I consider using an API gateway that has built-in quota rules? I'm looking to understand the industry standards for this kind of implementation.
5 Answers
Why complicate things? Just get the user's plan when they authenticate and apply rate limiting through middleware and caching. It’s straightforward, similar to what Laravel does with their RateLimiter. Just check the user's status and set the limits based on that.
For those request amounts, I’d suggest storing the limits in your database. With around 100 requests a month, it’s manageable as it only requires about three writes per user per day. Plus, you can avoid unnecessary complexities with external services.
Thanks for the insight! But if I go this way, I’ll need to create a system to check each user's plan and ensure they stay within limits. I'm trying to find a simpler approach.
I would start with Redis—it's simple and scales well when your user base grows. You could set up a countdown timer for each account with a TTL that resets at the end of the month. Each API call would reduce that count using Redis’ DECR command. For added transparency, keep a log of all the API calls made by clients, so they can see their usage at any time! If the counter isn’t in Redis yet, check the account type to determine the starting value. This way, you’re effectively tracking the limits per plan.
That does sound efficient. I was considering Redis but then worried if it’s necessary to implement such a solution for every product I launch. Thinking out loud about this now.
There's a solid article over at bytebytego that covers rate limiting, might be worth a read for more insights!
Ultimately, your decision should hinge on your specific requirements rather than mainstream standards. Consider what's best for your application and user needs.
I see your point, but asking for standard approaches is a good step when you're unsure. You can always deviate from those norms if your needs are unique.
That makes a lot of sense. I’ve been overthinking this. My current serverless setup feels unnecessarily complex for what I need.