Sidekiq and Redis: Their Role in Rails Background Processing Until Version 7

Before SolidQueue arrived with Rails 8, the de facto standard for production-grade background job processing in the Rails ecosystem was Sidekiq.

Introduced in 2012, Sidekiq radically improved how background jobs were handled by bringing multithreaded job execution and Redis-backed queuing to the Ruby world.

While Rails developers had already been using tools like Delayed Job and Resque, Sidekiq's performance, simplicity, and powerful feature set quickly made it the default choice for anything beyond small-scale or development setups.

Sidekiq works by pushing jobs into Redis lists, where background workers poll these queues, retrieve the job data, and execute the defined Ruby classes. Redis acts as an in-memory data store, which makes it fast and ideal for queueing workloads.

A key advantage was Sidekiq’s ability to execute multiple jobs concurrently using threads, leveraging Ruby’s improved concurrency models (especially with JRuby and later, Ruby 3’s Ractors and fiber-based scheduling).

Here’s what a typical Sidekiq job looked like:

#app/workers/notification_worker.rb
class NotificationWorker
  include Sidekiq::Worker

  def perform(user_id)
    user = User.find(user_id)
    UserMailer.notify(user).deliver_now
  end
end

#Enqueueing the job
NotificationWorker.perform_async(current_user.id)

In addition to high throughput, Sidekiq also came with features like:

By default, Sidekiq workers pull jobs from a queue named default, but it supports multiple named queues with prioritization.

For example, queues can be configured to favor critical tasks over low priority tasks:

#config/sidekiq.yml
:queues:
  - critical
  - default
  - low

In most Rails apps up to version 7, the queue adapter was often set to use Sidekiq as the backend for Active Job:

#config/application.rb
config.active_job.queue_adapter = :sidekiq

However, this setup came with infrastructure and operational overhead.

Redis had to be installed and managed alongside your app. Misconfigured Redis instances could lead to job loss or stale queues.

Developers needed to learn how to manage Redis-specific behaviors, such as persistence, memory management, eviction policies, and connection limits.

In complex deployments, Redis became a single point of failure if not highly available or replicated.

Moreover, licensing became a concern for some teams.

While Sidekiq’s open-source version was sufficient for many, some enterprise-level features—like batch jobs, workflows, rate limiting, and historical analytics—were locked behind Sidekiq Pro or Sidekiq Enterprise, which required a paid license.

Despite these concerns, Sidekiq was (and remains) incredibly stable, performant, and well-maintained. Its maturity and community support made it the go-to choice for job processing in Rails applications up to version 7. Many developers structured their background systems, alerts, and workflows around it.

However, as Rails applications matured and more teams began looking for tighter, more native integrations, the limitations of having an external, Redis-dependent system became more apparent—especially in smaller applications or monoliths looking for simplicity.

This growing appetite for a native solution is precisely what laid the groundwork for SolidQueue: a background job system built into Rails, free from external dependencies, yet flexible and robust enough to handle modern job processing needs.