finds.dev← search

// the find

ixti/sidekiq-throttled

★ 798 · Ruby · MIT · updated Jun 2026

Concurrency and rate-limit throttling for Sidekiq

sidekiq-throttled adds concurrency caps and rate limits to Sidekiq jobs, enforced at fetch time via Redis Lua scripts. It fits any Rails/Ruby app that needs to stop a job class from monopolizing workers or hammering an external API. Actively maintained and currently targeting Sidekiq 8.x only.

The Lua-based atomicity for concurrency locks and threshold counters means you don't get races under high parallelism — that's the right way to do this. Dynamic throttling via proc-based limits and key_suffix lets you express per-user or per-tenant rate limits without separate job classes. Multi-constraint support (e.g., 500/min AND 5000/hour on the same job) is genuinely useful and not common in alternatives. The cooldown manager that backs off polling a saturated queue is a real-world optimization most similar gems skip.

The 15-minute TTL on concurrency locks is a footgun for long-running jobs — if you forget to set a custom TTL and your job runs 20 minutes, the concurrency guarantee silently breaks. The `:schedule` requeue strategy requires you to tune avg_job_duration yourself, and the docs warn that setting it too low degrades scheduling under load, but there's no observability to tell you when that's happening. Web UI is minimal — you get a Throttled tab but no way to manually release stuck locks or inspect which keys are currently held. Sidekiq version support dropped to 8.x only, so if you're on an older Sidekiq (common in large monoliths), you're stuck on an older gem version.

View on GitHub →

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →