Enqueueing, Workers & Redis

Why Background Jobs

Sidekiq is a Redis-backed background job processing library for Ruby. Slow or non-essential work (sending an email, resizing an image) shouldn't make a user wait for a response — offloading it to a background job keeps the request fast while the work still happens shortly after. Redis is the queue/data store enqueued jobs sit in, chosen for its speed at this high-throughput role.

Workers & Enqueueing

class WelcomeEmailWorker
  include Sidekiq::Job

  def perform(user_id)
    user = User.find(user_id)  # re-fetch, don't pass the object itself
    UserMailer.welcome(user).deliver_now
  end
end

WelcomeEmailWorker.perform_async(user.id)
WelcomeEmailWorker.perform_in(1.hour, user.id)  # delayed

perform_async schedules the job asynchronously — calling code continues immediately without waiting. perform contains the actual work logic, called by a worker process later. Passing an ID (not the full ActiveRecord object) is standard practice: job arguments are serialized to JSON for storage in Redis, and re-fetching inside perform avoids serialization limits and stale-data issues between enqueue and execution time.

Queues, Threads & Scaling

Named queues (default, mailers, critical) let time-sensitive jobs get their own high-priority lane rather than waiting behind lower-priority work. A Sidekiq process polls Redis continuously and processes jobs using a thread pool — lighter-weight than one OS process per job, well suited to the I/O-bound nature of most background jobs. Scaling out means running more worker processes (potentially across machines) and sizing Redis to handle the volume.