By this point in the course, you're probably pretty comfortable with Sidekiq. It's the gold standard for a reason: it's fast, it's efficient, and it handles thousands of jobs per second without breaking a sweat. But there is a fundamental architectural trade-off happening under the hood that can bite you in the ass if you're dealing with "unstable" code. Sidekiq is multithreaded. That means one Ruby process is running multiple jobs simultaneously in different threads.

The Thread-Safety Gamble

Imagine you're building a feature that generates complex PDF reports using a library that wraps a C-extension—something like wkhtmltopdf. In a perfect world, this works great. But in the real world, some of these libraries have memory leaks or, worse, they occasionally cause a segmentation fault (a "segfault").

If you're using Sidekiq and one of those PDF jobs triggers a segfault, it doesn't just kill that one job. It kills the entire process. Because Sidekiq is running 25 other jobs in that same process, all 25 of those jobs are suddenly terminated mid-flight. You've just turned a single failing report into a cascading failure across your background queue. I've seen this happen in production where a single "poison pill" job would repeatedly crash the worker, effectively DOS-ing the system because Sidekiq would keep trying to pick it up and crashing again.

The Isolation Guarantee

This is where Resque comes in. While Sidekiq is multithreaded, Resque is fork-based. When a Resque worker picks up a job, it doesn't run it in a thread; it forks a completely new child process to handle that specific piece of work.

Going back to our PDF example: if the PDF generator leaks 500MB of RAM or hits a segfault and crashes, it only kills the child process. The parent worker process remains untouched, calmly notes that the child died, and moves on to the next job. The operating system handles the cleanup, and all that leaked memory is reclaimed instantly. It's a "burn after reading" approach to job execution. You get total isolation, which is an incredible safety net when you're forced to use unstable third-party binaries or legacy code that isn't thread-safe.

Trading RAM for Peace of Mind

Now, you might be wondering why we don't just use Resque for everything. The cost is memory. Forking a process is significantly "heavier" than spawning a thread. If you have a large Rails app, every time Resque forks, it carries over the memory footprint of your application (though Ruby's Copy-on-Write helps mitigate this). If you're running 50 workers, you're using way more RAM than 50 Sidekiq threads would.

I usually tell my team to think of it this way: Sidekiq is for your high-volume, "well-behaved" logic (sending emails, updating counters, syncing APIs). Resque is for the "dangerous" stuff (heavy image processing, PDF generation, shell-outs to unstable CLI tools). You don't even have to choose just one; you can actually run both in the same app, routing your stable jobs to Sidekiq and your volatile jobs to Resque.

# A typical Resque job looks remarkably like Sidekiq, 
# but the execution model is fundamentally different.
class MonthlyReportGenerator
  @queue = :heavy_lifting

  def self.perform(user_id)
    user = User.find(user_id)
    # If this method crashes the Ruby VM, only the fork dies.
    PDFGenerator.render(user.report_data) 
  end
end

📋 Practical Task

Migrating the Volatile PDF Worker to Resque

You have a Sidekiq worker called InvoicePdfWorker that is currently causing intermittent crashes in your production environment due to a memory leak in the underlying pdf-renderer gem. Your goal is to move this specific functionality to Resque to ensure process isolation.

• Create a new Resque job class named InvoicePdfJob.
• Define the @queue as :pdf_reports.
• Move the logic from the Sidekiq perform method into the Resque self.perform method.
• Update the call site in the InvoicesController to use Resque.enqueue(InvoicePdfJob, invoice_id) instead of InvoicePdfWorker.perform_async(invoice_id).
• Verify that the job is correctly enqueued by checking the Redis resque:queue:pdf_reports key.