Hacker News: 0megion

New comment by 0megion in "Show HN: Distributed Rate Limiter – 50K+ RPS, Redis-Backed, Production-Ready"

0megion — Thu, 02 Oct 2025 07:58:18 +0000

If requests are already hitting your servers, it’s too late — you’re burning CPU and bandwidth before rejecting. I built Rately to solve this at the edge: set limits by user, IP, or plan (e.g. free = 1k/day, pro = 1M/month) and return 429s before traffic reaches your infra. Keeps apps simple and protects backend capacity.

I built a service to make custom rate limiting less painful

0megion — Wed, 01 Oct 2025 09:49:07 +0000

Article URL: https://rately.dev

Comments URL: https://news.ycombinator.com/item?id=45435974

Points: 1

# Comments: 0

New comment by 0megion in "Testing a new rate-limiting service – feedback welcome"

0megion — Sat, 20 Sep 2025 08:34:18 +0000

Interesting, but still your Rail app needs to apply the rate limit logic working with Redis, maybe your DB will be protected, but you will still receive the traffic through your network, meaning more ingress cost, along with CPU to process all the incoming requests.

New comment by 0megion in "Testing a new rate-limiting service – feedback welcome"

0megion — Fri, 19 Sep 2025 14:02:39 +0000

It's already too late if requests are hitting your service. What happens when a customer sends x100 traffic all of a sudden, your Rails backend needs to scale or crash to handle the rate limiting.

New comment by 0megion in "Testing a new rate-limiting service – feedback welcome"

0megion — Fri, 19 Sep 2025 10:15:51 +0000

Correct, pricing would be based on the traffic volume.

New comment by 0megion in "Testing a new rate-limiting service – feedback welcome"

0megion — Fri, 19 Sep 2025 08:14:45 +0000

That is fair. Maybe Proxy mode would be a way to go in this case? Instead of calling another API, you can pass through your requests, and only a small amount can reach your origin.

Testing a new rate-limiting service – feedback welcome

0megion — Fri, 19 Sep 2025 07:24:48 +0000

Hey all,

I’m building a project called Rately. It’s a rate-limiting service that runs on Cloudflare Workers (so at the edge, close to your clients).

The idea is simple: instead of only limiting by IP, you can set rules based on your own data — things like:

- URL params (/users/:id/posts → limit per user ID)

- Query params (?api_key=123 → limit per API key)

- Headers (X-Org-ID, Authorization, etc.)

Example:

Say your API has an endpoint /user/42/posts. With Rately you can tell it: “apply a limit of 100 requests/min per userId”.

So user 42 and user 99 each get their own bucket automatically. No custom nginx or middleware needed.

It has two working modes:

- Proxy mode – you point your API domain (CNAME) to Rately. Requests come in, Rately enforces your limits, then forwards to your origin. Easiest drop-in.

``` Client ---> Rately (enforce limits) ---> Origin API ```

- Control plane mode – you keep running your own API as usual, but your code or middleware can call Rately’s API to ask “is this request allowed?” before handling it. Gives you more flexibility without routing all traffic through Rately.

``` Client ---> Your API ---> Rately /check (allow/deny) ---> Your API logic ```

I’m looking for a few developers with APIs who want to test it out. I’ll help with setup .

Comments URL: https://news.ycombinator.com/item?id=45298870

Points: 3

# Comments: 9