When I moved from building small apps to production-grade systems, I quickly realized not everything should happen inside a request/response cycle. That’s where background jobs became a game-changer.
Rails makes this easy with Sidekiq, a powerful background processing tool that uses Redis under the hood.
Imagine:
Sending emails after user signup
Processing image uploads
Syncing data with third-party APIs
Doing these inside a controller slows down the user experience. With background jobs, we push the heavy work to the side.
# Gemfile
gem 'sidekiq'
# config/application.rb
config.active_job.queue_adapter = :sidekiq
# app/jobs/welcome_email_job.rb
class WelcomeEmailJob < ApplicationJob
queue_as :default
def perform(user_id)
user = User.find(user_id)
UserMailer.welcome_email(user).deliver_now
end
end
Now, instead of sending an email directly, enqueue it:
# app/controllers/users_controller.rb
def create
@user = User.new(user_params)
if @user.save
WelcomeEmailJob.perform_later(@user.id)
redirect_to @user, notice: "User created successfully!"
else
render :new
end
end
Sidekiq comes with a web UI to monitor jobs.
# config/routes.rb
require 'sidekiq/web'
mount Sidekiq::Web => '/sidekiq'
Now visit /sidekiq in your browser to see job queues, retries, and failures.
At one point, I had to sync thousands of records from an external API. Running it in the controller would timeout. Using Sidekiq:
class SyncApiDataJob < ApplicationJob
queue_as :default
def perform
ExternalApi.fetch_records.each do |record|
ProcessRecordJob.perform_later(record)
end
end
end
This way, jobs ran in the background, workers scaled horizontally, and the app stayed fast.
Background jobs turned out to be one of the most important shifts in my career. They made apps scalable, reliable, and user-friendly. Today, whether it’s sending notifications, crunching data, or integrating APIs — I always think “Can this run in the background?” before adding it to a controller.