The Basics

Sidekiq is a framework for background job processing. It allows you to scale your application by performing work in the background. This requires three parts:

Client

The Sidekiq client runs in your web application process (typically a Rails unicorn or passenger process) and allows you to push jobs into the background for processing. There's three ways to create a job in your application code:

MyWorker.perform_async(1, 2, 3)
SomeClass.delay.some_class_method(1, 2, 3)                      # See Delayed Extensions wiki page
Sidekiq::Client.push('class' => MyWorker, 'args' => [1, 2, 3])  # Lower-level generic API
Sidekiq::Client.push('class' => 'MyWorker', 'args' => [1, 2, 3])  # Can also pass class as a string.

All three ways create a Hash which represents the job, serializes that Hash to a JSON string and pushes that String into a queue in Redis. This means the arguments to your worker must be simple JSON datatypes (numbers, strings, boolean, array, hash). Complex Ruby objects (e.g. Date, Time, ActiveRecord instances) will not serialize properly.

Redis

Redis provides data storage for Sidekiq. It holds all the job data along with runtime and historical data to power Sidekiq's Web UI.

Server

Each Sidekiq server process pulls jobs from the queue in Redis and processes them. Like your web processes, Sidekiq boots Rails so your jobs and workers have the full Rails API, including ActiveRecord, available for use. The server will instantiate your worker and pass the arguments. Everything else is up to your code.

Next you might want to read about Error Handling in your worker or Best Practices for designing your workers.