Sidekiq at Gusto: The Parts Where People’s Jaw Drops
summary
Gusto runs Sidekiq across Rails apps with real patterns: queue SLAs, autoscaling, Redis tuning, job repair, and shared gems, and the talk names concrete surprises — 170 million jobs per day (spikes to 270m), a hard primary database bottleneck before Redis or workers, and Redis’ single-threaded CPU limits. Built tools include a morg manager for bulk retries, a kill‑switch and auto‑rerouter to move noisy jobs, pause-on-high-db mechanisms, and payload metrics; many work but each has notable gotchas.
AI-written summary · about
chapters (24)
- 0:00Introduction
- 1:51Scaling jaw-drop moment
- 2:55Sidekiq team and on-call burden
- 4:19Three-tier job processing
- 5:01Sidekiq volume challenges
- 6:23Database bottleneck
- 7:04Latency queues and Q shards
- 9:09Readonly queues
- 9:30Sidekiq morgue and bulk jobs
- 10:56Kill switching jobs
- 12:19Rapid Sidekiq incidents
- 22:30Incident response improvements
- 23:35Latency queue issues
- 25:24Queue measurement gaps
- 26:26Auto rerouter friction
- 27:08Redis CPU limits
- 28:11Tracking job payloads
- 28:52Custom Sidekiq leader
- 29:35Fixing periodic jobs
- 30:17Observability challenges
- 31:20Team collaboration
- 32:41State mutation side effects
- 33:02Scaling Sidekiq future
- 33:44Closing and hiring
related talks
35mProcesses and Threads - Resque vs. Sidekiq
39mAsynchronous Workers to the Resque
55mThe Past, Present and Future of Background Job...
28mFair by design: orchestrating background jobs in Ruby
37mHow Small Changes Can Make Huge Waves
27mFrom Resque to SolidQueue - Rethinking our background jobs for...
41mInside ActiveJob
20mSolid Queue - Default Active Job Adaptor in Rails 8