Job processors: Sidekiq aware
This course compares Sidekiq with Solid Queue, the job backend this Rails app runs. It covers how a Sidekiq::Job class differs from this app's ActiveJob classes and where each system stores queued work: Redis or PostgreSQL. It explains what Redis persistence settings mean for durability. It also compares Sidekiq's automatic retries with opt-in retry_on, and threads in one process with dispatcher and worker pools. Sidekiq's Web UI is set against an app with no jobs dashboard. The last lesson weighs Rails' published reasoning against Sidekiq's benchmarks.
What you'll learn
- ✓How Sidekiq's native API (perform_async, perform_in, perform_at) differs from ActiveJob's perform_later
- ✓Why Sidekiq needs a separate Redis service and how RDB and AOF affect durability
- ✓How Sidekiq's default 25 retries compare with ActiveJob's opt-in retry_on and Solid Queue's failed executions
- ✓How Sidekiq threads and weighted queues compare with Solid Queue dispatchers and worker pools
- ✓What Sidekiq's Web UI shows and how its free and paid tiers differ
- ✓How to weigh Rails' stated reasoning and Sidekiq's benchmarks when choosing a job processor
Two philosophies, one job: Redis or the database
A background job is a promise to do something later: send an email, fetch an image, recalculate a stat. Between the moment your code says "do this later" and the moment a worker runs it, that promise has to sit somewhere durable enough to survive a deploy, a crash or a restart. Two…
Read the full lesson free →Curriculum
7 lessonsTwo philosophies, one job: Redis or the database
Introduces Sidekiq and Solid Queue as two ways to store pending jobs: Redis or the relational database.
Writing the job: Sidekiq::Job vs this app's ApplicationJob
Compares Sidekiq's native perform_async API with this app's ActiveJob classes and what an adapter swap would require.
Where the queue lives: Redis vs a PostgreSQL table
Explains Sidekiq's separate Redis dependency, Redis RDB and AOF persistence, and Solid Queue rows stored in PostgreSQL.
Retries: Sidekiq's automatic backoff vs opt-in retry_on
Compares Sidekiq's default 25 retries with backoff against ActiveJob's opt-in retry_on and where exhausted jobs end up.
Running the work: threads vs dispatcher/worker processes
Contrasts Sidekiq's threads in one process and weighted queues with this app's dispatcher and three worker pools.
Watching it run: Sidekiq's Web UI vs no dashboard here
Shows how Sidekiq's Web UI mounts in routes, notes this app has no jobs dashboard, and lists paid tiers.
Putting it together: choosing a job processor on the evidence
Weighs Rails' published case for Solid Queue against Sidekiq's benchmarks and the facts that shaped this app's choice.