Show HN: Goralim - a rate limiting pkg for Go to handle distributed workloads
1–10 of 30 posts
Re: Show HN: Goralim - a rate limiting pkg for Go to handle distributed workloads
#2a minimal rate limiting package for Golang microservice. small weekend project. feedback and stars will be appreciated.
Re: Show HN: Goralim - a rate limiting pkg for Go to handle distributed workloads
#3a minimal rate limiting package for Golang microservice. small weekend project. feedback and stars will be appreciated.
To avoid race conditions with concurrent requests better to use Redis Lua. See this example: https://gist.github.com/ptarjan/e38f45f2dfe601419ca3af937fff...
Re: Show HN: Goralim - a rate limiting pkg for Go to handle distributed workloads
#4> It is capabale to handle distributed workload with its redis database support
sounds like this is limited by redis. For many organizations, this is fine. At my last gig, we used redis for deduplication and it required over 150 redis nodes with deterministic routing and consensus. Redis reportedly could support 200k rps per node, but in our case, we wouldn't see it get passed around 50k rps no matter how we tuned it.
An interesting addition to this library would be to use an interface and allow your backing datastore of choice allowing teams to use redis, zookeeper, an in-mem Go instance of the same library, sql, etc.
A fun exercise would be to figure out how to make the rate limiting itself distributed so you don't need a single store keeping everything in sync. Maybe a combo of deterministic request routing in a ring topology
Re: Show HN: Goralim - a rate limiting pkg for Go to handle distributed workloads
#5a minimal rate limiting package for Golang microservice. small weekend project. feedback and stars will be appreciated.
To avoid race conditions with concurrent requests better to use Redis Lua. See this example: https://gist.github.com/ptarjan/e38f45f2dfe601419ca3af937fff...
For this general pattern implemented in Golang, check out redis_rate:
https://github.com/ductone/redis_rate
This fork also implements Redis Client Pipelining to check multiple limits at the same time, and Concurrency Limits.
Re: Show HN: Goralim - a rate limiting pkg for Go to handle distributed workloads
#6Given most of the backends use round robin for loadbalancing, having in-memory counter should be enough. Removing redis as downstream dependency is a big win.
For the redis implementation, there should be fallback to in-memory counting instead blocking altogether. Currently the redis is a SPOF for the entire service.
Re: Show HN: Goralim - a rate limiting pkg for Go to handle distributed workloads
#7> It is capabale to handle distributed workload with its redis database support sounds like this is limited by redis. For many organizations, this is fine. At my last gig, we used redis for deduplication and it required over 150 redis nodes with deterministic routing and consensus. Redis reportedly could support 200k rps per node, but in our case, we wouldn't see it get passed around 50k rps no matter how we tuned it…
RPS meaning reads or writes? What's the distribution of message sizes, and how large is your total dataset? What specs (core count, NIC) did each node have?
I'm asking because without this info, RPS is not a particularly useful metric. As an extreme example, if your dataset is <1MB, you could likely serve read-heavy requests from your SmartNIC's dcache at close to line rate.
Re: Show HN: Goralim - a rate limiting pkg for Go to handle distributed workloads
#8a minimal rate limiting package for Golang microservice. small weekend project. feedback and stars will be appreciated.
There aren't any tests...?
If folks are looking for a serious rate limiting package for Go, limiter is a good start: https://github.com/ulule/limiter
Re: Show HN: Goralim - a rate limiting pkg for Go to handle distributed workloads
#9see also: https://github.com/Clever/sphinx
Re: Show HN: Goralim - a rate limiting pkg for Go to handle distributed workloads
#10Given most of the backends use round robin for loadbalancing, having in-memory counter should be enough. Removing redis as downstream dependency is a big win. For the redis implementation, there should be fallback to in-memory counting instead blocking altogether. Currently the redis is a SPOF for the entire service.
if you're round robining clients w/o sticky assignment then you're going to get nodes*limit consumption. Not correct.
Also if you give limit/nodes per node and random assign a connection, you get correct answers on average, but a really janky pattern at the edge case (a user gets a 429, and retries and succeeds, then gets 429 again as they consume those last few requests).