Sidekiq Setup Basics
Fast recall
Quick revision
Core answer
sidekiq gem, provide a supported Redis-compatible server and URL, configure the queues and worker concurrency, and start a Sidekiq server process separately from the Rails web process. Native jobs include Sidekiq::Job; Active Job applications set config.active_job.queue_adapter = :sidekiq. The producer and worker must share compatible code, queue names, and serialization expectations. Production setup also needs authentication for the Web UI, graceful shutdown, error reporting, and queue health monitoring.Whether you know the Sidekiq setup steps: gem, adapter/worker, Redis config, bundle exec sidekiq, Web UI mount.
Exposing the Sidekiq Web UI without auth in production (anyone could retry/kill jobs).
Sidekiq setup: gem 'sidekiq'; adapter = :sidekiq or include Sidekiq::Job; Redis config; bundle exec sidekiq; mount Sidekiq::Web (protect it).
Interview-ready guide
Interview answer
Sidekiq has a client side and a server side. Rails code serializes a job and pushes it to a queue in a supported Redis-compatible data store. A separate Sidekiq process fetches jobs and runs several Ruby threads, so both the data-store connection and the application dependencies used by jobs must be available there.
Setup begins by adding the Sidekiq gem and configuring the connection URL through deployment configuration. Native job classes include Sidekiq::Job. If the application uses Rails Active Job, it instead selects :sidekiq as the queue adapter and enqueues through perform_later.
For example, config/sidekiq.yml can list critical, default, and mailers, while the deployed worker starts with that configuration. A job sent to a queue no running process consumes will remain queued even though enqueueing succeeded.
Concurrency must match available database connections, external-service limits, and CPU or memory behaviour. Increasing threads without increasing the Active Record pool can make workers wait for connections; increasing both without checking the database can move the bottleneck downstream.
A production-ready setup includes graceful shutdown so workers can stop safely, structured error reporting, retries and dead-job visibility, queue depth and latency monitoring, and authenticated access to any mounted Sidekiq Web interface. A local successful job proves code wiring, not operational reliability.
Sidekiq Setup Basics
Direct Answer
To run Sidekiq with Rails, add the sidekiq gem, provide a supported Redis-compatible server and URL, configure the queues and worker concurrency, and start a Sidekiq server process separately from the Rails web process. Native jobs include Sidekiq::Job; Active Job applications set config.active_job.queue_adapter = :sidekiq. The producer and worker must share compatible code, queue names, and serialization expectations. Production setup also needs authentication for the Web UI, graceful shutdown, error reporting, and queue health monitoring.
Deep Dive & Architecture
The web process only needs client configuration to enqueue, while the Sidekiq server boots the Rails application to execute job code. A deployment can therefore have healthy web instances and no functioning workers. Process supervision and health checks must treat them as separate services.
Queue configuration is routing. The payload names a queue, and a worker process declares which queues it polls. Strict priority can starve low-priority work when high-priority traffic never clears; weighted or specialised processes trade strict ordering for capacity isolation. Fewer purposeful queues are easier to operate than one per feature.
Sidekiq concurrency is threaded within each process. Every blocking job may hold a database connection or network socket. Pool sizes, client timeouts, thread safety, and downstream quotas must be coordinated with total concurrency across all worker processes, not tuned from a single machine in isolation.
The Web interface exposes operational state and can retry or delete work, so mounting it without authentication creates an administrative vulnerability. Logs and metrics should identify job class, queue, runtime, retry count, and a safe business correlation key without placing secrets in job arguments.
Code Example
# config/application.rb
class Application < Rails::Application
config.active_job.queue_adapter = :sidekiq
end
# config/sidekiq.yml
# :concurrency: 5
# :queues:
# - critical
# - default
# - mailers
# Start separately from the Rails web server:
# bundle exec sidekiq -C config/sidekiq.yml
Common Mistakes & Pitfalls
Exposing the Sidekiq Web UI without auth in production (anyone could retry/kill jobs).
Check your understanding
Answer these without looking back at the article.
- Why can jobs stay queued while the Rails website remains healthy?
- How does Sidekiq concurrency relate to the Active Record connection pool?
- Why must access to Sidekiq Web be authenticated?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.