How Does Sidekiq Work?
Redis-based Background Job Queue System
Sidekiq is Ruby's most popular background job processor. Time-consuming tasks during web requests are serialized as jobs and placed in a Redis queue (perform_async), and separate Sidekiq worker processes dequeue and process them using multiple threads. The web process can return an immediate response while actual work happens in the background. Failed jobs are automatically retried, and dead jobs can be monitored via the web UI.
Architecture Diagram
- Web and worker processes are <strong>separate processes</strong> (same codebase)
- Redis acts as queue — jobs are serialized as JSON
- BRPOP: blocks when queue is empty (not polling)
- Worker processes multiple jobs concurrently with multithreading
How It Works
MyWorker.perform_async(args) called from web request
Job info serialized to JSON and LPUSH to Redis queue
Sidekiq worker process dequeues job from Redis via BRPOP
Worker executes perform(args) method (separate thread)
On success job removed, on failure moved to retry queue (exponential backoff)
Moves to Dead queue when max retries exceeded (manual review needed)
Pros
- ✓ Improved web response speed (heavy tasks offloaded)
- ✓ Automatic retry (exponential backoff)
- ✓ High throughput via multi-threading
- ✓ Monitoring via Sidekiq Web UI
Cons
- ✗ Redis dependency (Redis down = job processing halted)
- ✗ Job serialization constraints (cannot pass complex objects)
- ✗ Thread safety concerns
- ✗ Possible duplicate execution (idempotency needed)