Rails 2026'da Arka Plan Görevleri: Sidekiq vs Good Job Karşılaştırması ve Mülakat Soruları

Ruby on Rails'de arka plan görevleri (background jobs), Rails 8.x ve Solid Queue'nun varsayılan Active Job backend'i olarak tanıtılmasıyla önemli bir evrim geçirdi. Sidekiq, Good Job ve Solid Queue arasındaki seçim, verimlilik gereksinimleri, altyapı kısıtlamaları ve projenin ihtiyaç duyduğu özelliklere bağlıdır.

Active Job Arka Plan İşlemeyi Nasıl Birleştirir

Active Job, Rails'de arka plan çalışmalarını bildirme, kuyruğa alma ve yürütme için standartlaştırılmış bir arayüz sağlar. Framework, kuyruk backend'leri arasındaki farkları soyutlayarak kodun Sidekiq, Good Job, Solid Queue veya herhangi bir adapter arasında taşınabilir kalmasını sağlar.

# app/jobs/payment_processor_job.rb
class PaymentProcessorJob < ApplicationJob
  queue_as :critical
  retry_on Stripe::RateLimitError, wait: :polynomially_longer, attempts: 5
  discard_on Stripe::InvalidRequestError

  def perform(order_id)
    order = Order.find(order_id)
    PaymentService.process(order)
    OrderMailer.confirmation(order).deliver_later
  end
end

retry_on ve discard_on callback'leri, backend'e özgü kod olmadan geçici arızaları ve kalıcı hataları yönetir. queue_as direktifi öncelik atar ve her backend bunu kendi kuyruk işleme stratejisine göre yorumlar.

Sidekiq 8.x: Redis Destekli Yüksek Verimlilik

Sidekiq, Rails arka plan görevleri için performans standardı olmaya devam etmektedir. 8.x sürüm serisi Ruby 3.2+, Rails 7.0+ ve Redis 7.2+ gerektirir (Valkey ve Dragonfly, Redis lisans değişikliğinden sonra drop-in değiştirme olarak çalışır).

# config/initializers/sidekiq.rb
Sidekiq.configure_server do |config|
  config.redis = { url: ENV.fetch('REDIS_URL') }
  config.concurrency = 10
end

Sidekiq.configure_client do |config|
  config.redis = { url: ENV.fetch('REDIS_URL') }
end

Sidekiq 8 üç önemli değişiklik getirdi: CSS'i 160KB'dan 16KB'a ve ortalama sayfa render süresini 55ms'den 3ms'e düşüren sıfırdan yeniden yazılmış Web UI, yeni Profiles sekmesi altında Vernier ile görev profilleme ve 72 saate kadar tutulan görev metrikleri.

Sidekiq Ne Zaman Mantıklıdır

Sidekiq, sürdürülebilir verimlilik, milisaniye altı görev alma gecikmesi veya hız sınırlama ve benzersiz görevler gibi enterprise özelliklerin Redis çalıştırmayı haklı kıldığı iş yüklerine uygundur. 7.0'da tanıtılan ve artık standart olan Capsules, tek bir Sidekiq sürecinin kendi eşzamanlılık ve kuyruklarına sahip birden fazla izole thread havuzu çalıştırmasına olanak tanır.

# config/sidekiq.yml
:concurrency: 10
:queues:
  - [critical, 3]
  - [default, 2]
  - [low, 1]

# İzole işleme için Capsules
:capsules:
  imports:
    :concurrency: 2
    :queues:
      - imports

Gömme API'si ayrıca küçük uygulamalar için Sidekiq'in Puma süreci içinde çalışmasına izin verir, Solid Queue'nun Puma eklentisinin çalışma şekline benzer.

Good Job 4.x: PostgreSQL-Native Batch'ler ve Benzersizlik

Good Job, görev alma için PostgreSQL'in LISTEN/NOTIFY'ını ve bir kez çalıştırma güvenliği için advisory lock'ları kullanır. Sürüm 4.19.x (Eylül 2026 itibarıyla güncel) Rails 6.1+ ve Ruby 3.0+ destekler.

# config/application.rb
config.active_job.queue_adapter = :good_job

# config/initializers/good_job.rb
Rails.application.configure do
  config.good_job.execution_mode = :async
  config.good_job.max_threads = 5
  config.good_job.poll_interval = 5
  config.good_job.shutdown_timeout = 25
end

Good Job, batch'leri ve benzersiz görevleri açık kaynak katmanında sunar — Sidekiq'in ücretli lisanslara ayırdığı özellikler. perform_later çağrısı, çağıran kodla aynı veritabanı işlemi içinde good_jobs tablosuna bir satır ekler, böylece işlem geri alınırsa görev asla oluşturulmaz.

Lisans Olmadan Batch'ler

# app/jobs/batch_import_job.rb
class BatchImportJob < ApplicationJob
  def perform(batch, params)
    batch.on(:finish, ImportCompletionJob, params)
    
    params[:file_ids].each do |file_id|
      batch.add do
        ProcessFileJob.perform_later(file_id)
      end
    end
  end
end

# Batch'i kuyruğa ekle
GoodJob::Batch.enqueue do |batch|
  BatchImportJob.perform_later(batch, file_ids: [1, 2, 3])
end

İdempotentlik için Benzersiz Görevler

# app/jobs/sync_inventory_job.rb
class SyncInventoryJob < ApplicationJob
  include GoodJob::ActiveJobExtensions::UniqueJob

  good_job_control_concurrency_with(
    perform_limit: 1,
    key: -> { "sync_inventory_#{arguments.first}" },
    duration: 1.hour
  )

  def perform(warehouse_id)
    InventorySync.run(warehouse_id)
  end
end

perform_limit: 1 kısıtlaması, herhangi bir zamanda depo başına yalnızca bir senkronizasyonun çalışmasını sağlar ve aynı görev birden çok kez kuyruğa alındığında yinelenen çalışmayı önler.

Solid Queue: Rails 8 Varsayılanı

Solid Queue, görevleri uygulama veritabanında FOR UPDATE SKIP LOCKED kullanarak depolar — normal bir tabloyu görev kuyruğuna dönüştüren bir PostgreSQL ve MySQL özelliği. Yeni Rails 8 uygulamaları varsayılan olarak Solid Queue ile yapılandırılmış olarak gelir.

# config/solid_queue.yml
production:
  dispatchers:
    - polling_interval: 1
      batch_size: 500
  workers:
    - queues: "*"
      threads: 5
      polling_interval: 0.1

Solid Queue, SOLID_QUEUE_IN_PUMA=true ile Puma web sunucusu süreci içinde çalışabilir, bu da özel worker süreçlerine ihtiyaç duymayan uygulamalar için dağıtımı basitleştirir. Görevler veritabanı tablolarında kalıcı olarak depolanır, harici bağımlılıklar olmadan süreç yeniden başlatmalarını ve dağıtımlarını atlatır.

Özellik Karşılaştırma Tablosu

Rails Arka Plan Görevleri Mülakat Soruları

Teknik mülakatlar genellikle görev güvenilirliği, yeniden deneme stratejileri ve mimari kararların anlaşılmasını araştırır. Aşağıda deneyimli adayları ayırt eden sorular yer almaktadır.

S1: retry_on backend'e özgü yeniden deneme mantığından nasıl farklıdır?

retry_on, tüm backend'lerde çalışan bir Active Job callback'idir. Belirli istisnaları yakalar, bir bekleme stratejisi uygular (:polynomially_longer üstel olarak geri çekilir) ve görevi yeniden kuyruğa alır. Sidekiq'in sidekiq_retry_in gibi backend'e özgü yeniden deneme mantığı yalnızca o backend ile çalışır ve Active Job'un davranışını geçersiz kılabilir.

# Active Job yeniden deneme (taşınabilir)
class ApiSyncJob < ApplicationJob
  retry_on Net::OpenTimeout, wait: :polynomially_longer, attempts: 8
  
  def perform(record_id)
    ExternalApi.sync(record_id)
  end
end

S2: Görevi kuyruğa alan veritabanı işlemi geri alınırsa göreve ne olur?

Veritabanı destekli kuyruklarda (Good Job, Solid Queue), görev satırı işlemin bir parçasıdır, bu nedenle her şeyle birlikte geri alınır. Redis destekli kuyruklarda (Sidekiq), görev işlem tamamlanmadan önce Redis'te zaten mevcuttur ve yetim görevler oluşturur. Çözüm after_commit callback'leridir:

# Sidekiq için doğru desen
class Order < ApplicationRecord
  after_commit :enqueue_confirmation, on: :create

  private

  def enqueue_confirmation
    OrderConfirmationJob.perform_later(id)
  end
end

S3: Good Job ne zaman Sidekiq'i geçer?

Good Job, Redis'in operasyonel maliyeti verimlilik avantajlarını aştığında Sidekiq'i geçer. Günde 50.000'den az görev işleyen uygulamalar için, PostgreSQL destekli kuyruklar ayrı bir Redis kümesinin altyapı, izleme ve yük devretme karmaşıklığından kaçınır. Good Job ayrıca lisans ücreti olmadan batch'ler ve benzersiz görevler sağlar, bu da bu özelliklere bütçe dahilinde ihtiyaç duyan ekipler için önemlidir.

S4: Görev idempotentliğini ve yeniden denemeler için neden önemli olduğunu açıklayın

İdempotentlik, aynı görevi birden çok kez çalıştırmanın bir kez çalıştırmakla aynı sonucu üretmesi anlamına gelir. Görevler idempotent olmalıdır çünkü ağ arızaları, süreç çökmeleri veya zaman aşımı işleme yinelenen yürütmelere neden olabilir. Teknikler arasında veritabanında benzersiz kısıtlamalar, işlemeden önce mevcut sonuçları kontrol etme ve ödeme API'leri için harici idempotentlik anahtarları kullanma yer alır.

# İdempotent ödeme işleme
def perform(order_id, idempotency_key)
  return if Payment.exists?(idempotency_key: idempotency_key)
  
  Payment.create!(
    order_id: order_id,
    idempotency_key: idempotency_key,
    amount: Order.find(order_id).total
  )
end

S5: Dağıtılmış worker'larda tam olarak bir kez çalışması gereken görevler nasıl ele alınır?

Dağıtılmış kilitler eşzamanlı yürütmeyi önler. Good Job, PostgreSQL advisory lock'larını kullanır. Sidekiq Enterprise benzersiz görevler sunar. Manuel uygulama için Redis SETNX veya PostgreSQL pg_try_advisory_lock kullanılabilir:

class ExclusiveJob < ApplicationJob
  def perform(resource_id)
    lock_key = "exclusive_job:#{resource_id}"
    
    ActiveRecord::Base.connection.execute(
      "SELECT pg_try_advisory_lock(hashtext('#{lock_key}'))"
    ).first['pg_try_advisory_lock'] or return
    
    begin
      process_resource(resource_id)
    ensure
      ActiveRecord::Base.connection.execute(
        "SELECT pg_advisory_unlock(hashtext('#{lock_key}'))"
      )
    end
  end
end

Rails Arka Plan Görevleri için Doğru Backend'i Seçme

• Stack'te henüz Redis olmayan yeni Rails 8 projeleri için Solid Queue ile başlanması önerilir
• Görev hacmi günlük 50.000'i aştığında veya 100ms altı alma gecikmesi önemli olduğunda Sidekiq'e geçiş yapılabilir
• Batch'ler, benzersiz görevler veya lisans maliyeti olmadan cron zamanlama gerektiren yalnızca PostgreSQL dağıtımları için Good Job tercih edilebilir
• İşlem geri alındığında yetim görevlerden kaçınmak için Sidekiq ile görevleri kuyruğa alırken after_commit callback'leri kullanılmalıdır
• Yeniden denemeler ve dağıtılmış işleme yinelenen yürütmelere neden olabileceğinden her görev idempotent yapılmalıdır
• Mülakatlar için işlemsel görev kuyruğa alma, yeniden deneme stratejileri ve dağıtılmış kilitleme kalıplarının anlaşılması gösterilmelidir