I want to talk about one of the most common mistakes I see developers make when their app starts to grow: doing too much work during the request-response cycle. Imagine you're building a user registration flow. You've got the user's details, you've saved them to the database, and now you want to send a "Welcome!" email. It seems simple enough to just call your mailer right there in the controller and move on.

The "Just Do It Now" Trap

In a naive implementation, your code probably looks something like this:

def create
  @user = User.new(user_params)
  if @user.save
    UserMailer.welcome_email(@user).deliver_now
    redirect_to dashboard_path, notice: "Welcome aboard!"
  end
end

On your local machine with one user, this feels instantaneous. But here is where it breaks in production. Sending an email requires a network request to an external provider like SendGrid or Postmark. If that provider takes two seconds to respond, your user is staring at a white screen for two seconds. If the provider is down or timing out, your entire registration process crashes with a 500 error, even though the user was actually saved to the database. You've tied the availability of your core business logic to a third-party API. That's a gamble I'm not willing to take.

Offloading the Heavy Lifting

The better way—the professional way—is to treat the email not as a part of the request, but as a "job" to be done later. This is where Sidekiq comes in. Instead of forcing the user to wait, we tell Sidekiq, "Hey, here is a user ID; send them a welcome email whenever you have a spare millisecond," and we immediately redirect the user to their dashboard.

First, we move the logic into a Worker class:

class WelcomeEmailWorker
  include Sidekiq::Worker

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

Then, in the controller, we swap the direct call for perform_async:

def create
  @user = User.new(user_params)
  if @user.save
    WelcomeEmailWorker.perform_async(@user.id)
    redirect_to dashboard_path, notice: "Welcome aboard!"
  end
end

Notice that I passed the user_id and not the whole user object. This is a crucial detail. Sidekiq stores job arguments in Redis as JSON. If you pass a complex Ruby object, you're serializing a snapshot of that object. If the user changes their email address in the split second between the job being queued and the job being executed, the worker would be using stale data. Always pass simple identifiers.

The Price of Asynchronousity

Now, I'll be honest with you: this isn't a "free" upgrade. By introducing Sidekiq, you've just added two new pieces of infrastructure to your stack: Redis (to hold the queue) and a separate Sidekiq process (to execute the jobs). You now have to monitor that process. If the Sidekiq process crashes, your users will sign up just fine, but they'll never get their emails, and you won't know it until someone complains.

However, the trade-off is almost always worth it. You get automatic retries—if the email API is down for five minutes, Sidekiq will exponentially back off and try again until it succeeds. More importantly, your application remains snappy. Your users get an immediate response, and your web workers are freed up to handle the next request instead of idling while waiting for a remote server to say "OK."

📋 Practical Task

Exercise: Implementing a Background Image Processor

Imagine you are building a profile page where users upload a high-resolution avatar. Processing this image (resizing, cropping, and uploading to S3) is too slow to do in the controller and is causing request timeouts.

Your Goal: Refactor the synchronous image processing logic into a Sidekiq worker.

• Create a ProfileImageWorker class that includes Sidekiq::Worker.
• Implement a perform method that accepts a user_id.
• Inside the worker, simulate the processing work by calling a hypothetical ImageService.process_avatar(user) method.
• Modify a hypothetical UsersController#update_avatar action so that it no longer calls the ImageService directly, but instead queues the ProfileImageWorker using perform_async.
• Ensure you are passing the id of the user to the worker, not the user object itself.