Hey HN community! I've been working on something I think you'll find pretty neat: a Rate Limit API. It's a tool I built with the goal of tackling the challenges of API rate limiting, especially in distributed systems.
One of the core ideas behind this project was to make it dead simple to use, kind of like what Stripe did for payments. I wanted developers to be able to integrate rate limiting into their systems without the usual complexity. You'll find examples in JavaScript, Python, and Ruby to get you started in no time.
Let's talk about distributed counting – it's a tough nut to crack. In a distributed system, maintaining a consistent rate limit across multiple servers is tricky. There's a lot of coordination and data syncing involved, which can be a real headache. This API abstracts all that complexity away. It provides a centralized, consistent approach to rate limiting, so you don't have to worry about the underlying challenges.
On the pricing front, it's free for up to 1 million requests per month. We've got more flexible plans for higher volumes, all aiming to keep your costs reasonable.
I'd really appreciate your thoughts on this, especially around the ease of use and the distributed counting solution. If you've ever felt the strain of managing API traffic, especially in a distributed environment, I'm keen to hear how this might fit into your workflow.
I like the simplicity of the landing page! For me personally, the tool would be more useful if I could adjust the duration and the rate limit count without redeploying my code, but I'd also sooner spin up my own Redis instance than use a 3rd party service - so I'm not sure if my feedback is useful :)
PS: You can simplify and make the Python example a bit more secure by using the params parameter[0] instead of building the query string manually:
Thank you! I just pushed an update to the website to use the params parameter.
I'd love to make this more ergonomic for you. I'm used to using configuration propagation mechanisms where you can change configs without redeploying code (basically the webserver subscribes to some central pubsub config store). That paradigm works with this since you could parameterize the duration using the config value. What would work better for you?
That makes sense if you already have a pub/sub service running. But if you have a pub/sub service running, you probably also have a service that can count events so you won't need ratelimitapi.com.
In this case, I'm guessing the ability to configure the rate limits on your end would be useful. But again, I'm not your potential customer, so don't take this as customer feedback/feature request. I'm just thinking out loud :)
Touche! I guess we'll see if it's an issue in practice. My intuition is people won't change durations that frequently in practice. eg. OpenAI has a limit of 40 messages per 3 hours and hasn't changed that for months.
One of the core ideas behind this project was to make it dead simple to use, kind of like what Stripe did for payments. I wanted developers to be able to integrate rate limiting into their systems without the usual complexity. You'll find examples in JavaScript, Python, and Ruby to get you started in no time.
Let's talk about distributed counting – it's a tough nut to crack. In a distributed system, maintaining a consistent rate limit across multiple servers is tricky. There's a lot of coordination and data syncing involved, which can be a real headache. This API abstracts all that complexity away. It provides a centralized, consistent approach to rate limiting, so you don't have to worry about the underlying challenges.
On the pricing front, it's free for up to 1 million requests per month. We've got more flexible plans for higher volumes, all aiming to keep your costs reasonable.
I'd really appreciate your thoughts on this, especially around the ease of use and the distributed counting solution. If you've ever felt the strain of managing API traffic, especially in a distributed environment, I'm keen to hear how this might fit into your workflow.
Can't wait to hear what you guys think!
JR