Rails 8'de Solid Queue ve Solid Cache: 2026 Teknik Mülakat Hazırlık Rehberi

Rails 8, framework tarihindeki en kapsamlı altyapı dönüşümünü beraberinde getirmektedir. Solid Queue ve Solid Cache, arka plan görevleri ve önbellekleme için varsayılan bileşenler olarak Redis'in yerini almaktadır. Veritabanı destekli bu alternatifler, operasyonel karmaşıklığın önemli bir katmanını tamamen ortadan kaldırmaktadır.

Solid Queue Redis Tabanlı Görev Kuyruklarının Yerini Nasıl Alıyor

Solid Queue, görevleri doğrudan PostgreSQL, MySQL veya SQLite'ta saklayan veritabanı destekli bir Active Job arka planıdır. Temel mekanizma FOR UPDATE SKIP LOCKED — PostgreSQL 9.5+ ve MySQL 8+'de bulunan bu SQL özelliği, normal bir veritabanı tablosunu bloklama olmadan eşzamanlı bir görev kuyruğuna dönüştürmektedir.

Mimari üç bileşenden oluşmaktadır:

• Workers — solid_queue_ready_executions tablosunu sorgulayarak SKIP LOCKED ile görevleri talep eder
• Dispatchers — zamanlanmış görevleri solid_queue_scheduled_executions tablosundan hazır tablosuna taşır
• Schedulers — yapılandırmada tanımlanan tekrarlayan görevleri yönetir

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

Bu yapılandırma, her biri 5 iş parçacığına sahip iki worker süreci çalıştırarak 100 ms aralıklarla veritabanını sorgulamaktadır. Dispatcher, zamanlanmış görevleri saniyede bir kontrol ederek 500'lük gruplar halinde işlemektedir.

Rails 8'de İşlemsel Görev Kuyruğa Alma

Solid Queue'nun Redis tabanlı alternatiflere karşı en güçlü argümanlarından biri işlemsel kuyruğa almadır. Bir görev veritabanı işlemi içinde kuyruğa alındığında, yalnızca işlem başarıyla tamamlandıktan sonra görünür hale gelmektedir. Redis tabanlı arka planlar bu garantiyi sunamaz — bir görev, onu tetikleyen işlem tamamlanmadan önce çalışabilir ve henüz mevcut olmayan kayıtlara referans verebilir.

# app/jobs/send_welcome_email_job.rb
class SendWelcomeEmailJob < ApplicationJob
  self.enqueue_after_transaction_commit = true

  queue_as :default

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

# app/models/user.rb
class User < ApplicationRecord
  after_create do
    SendWelcomeEmailJob.perform_later(id)
    # Job only enqueued after the CREATE transaction commits
    # No risk of the job running before the user record exists
  end
end

enqueue_after_transaction_commit etkinleştirildiğinde, görev yalnızca kapsayıcı işlem başarılı olduktan sonra kuyruğa eklenmektedir. İşlem geri alınırsa görev hiçbir zaman kuyruğa girmemektedir. Bu yaklaşım, Redis tabanlı kuyrukları etkileyen yarış koşullarını (race conditions) tamamen ortadan kaldırmaktadır.

Eşzamanlılık Kontrolleri ve Öncelikli Kuyruklar

Solid Queue, Sidekiq'in yalnızca ücretli Enterprise sürümünde sunduğu yerleşik eşzamanlılık kontrolleri sağlamaktadır. limits_concurrency seçeneği, belirli bir türdeki görevlerin aynı anda kaç tanesinin çalışabileceğini sınırlamaktadır.

# app/jobs/api_sync_job.rb
class ApiSyncJob < ApplicationJob
  limits_concurrency to: 3, key: ->(account_id) { "api_sync_#{account_id}" }

  def perform(account_id)
    account = Account.find(account_id)
    ExternalApi.sync(account)
  end
end

Bu kod, hesap başına en fazla 3 API senkronizasyon görevinin eşzamanlı çalışmasını garanti etmektedir. Engellenen görevler solid_queue_blocked_executions tablosunda saklanır ve bir slot açıldığında otomatik olarak serbest bırakılır.

Öncelik iki düzeyde çalışmaktadır: görev başına sayısal öncelik (düşük sayı = yüksek öncelik) ve worker yapılandırmasındaki kuyruk sıralaması. Her iki mekanizma birleştirilerek görev yürütme sırası üzerinde hassas kontrol sağlanabilmektedir.

Gruplu İşlemler İçin Görev Yığınları (Batches)

Solid Queue 1.7.0, görevlerin gruplandırılmasına ve bir set olarak izlenmesine olanak tanıyan görev yığınlarını tanıtmıştır. Bu özellik, bir yığındaki tüm görevler tamamlandığında geri çağırmaların (callbacks) tetiklenmesini sağlar — daha önce Sidekiq Pro gerektiren bir desen.

# app/jobs/batch_import_job.rb
class BatchImportJob < ApplicationJob
  def perform(file_id)
    file = ImportFile.find(file_id)
    
    SolidQueue::Batch.enqueue(
      on_finish: BatchFinishedJob,
      on_success: NotifyUserJob,
      on_failure: AlertOpsJob
    ) do |batch|
      file.rows.each_slice(100) do |rows|
        ProcessRowsJob.perform_later(rows.map(&:id))
      end
    end
  end
end

Yığın, bloğu içinde kuyruğa alınan tüm görevleri izlemektedir. Tüm görevler tamamlandığında, başarı veya başarısızlıktan bağımsız olarak on_finish tetiklenmektedir. Tüm görevler başarılı olursa on_success, herhangi bir görev başarısız olursa on_failure çalışmaktadır. Bu yapı, son adımın tüm parçaların tamamlanmasını beklemesi gereken içe aktarma işleme gibi iş akışlarını mümkün kılmaktadır.

Yığın dışında oluşturulan ancak içinde kuyruğa alınan görevler o yığına katılmaktadır. Hiç görev olmadan biten bir yığın anında tamamlanır ve geri çağırmalarını hemen tetiklemektedir.

I/O Yoğun İş Yükleri İçin Fiber Yürütme Modu

Solid Queue 1.6.0, Async gem'ini kullanarak fiber tabanlı worker yürütme eklemiştir. Bu mod, görevleri iş parçacıkları yerine fiberlar üzerinde çalıştırmakta olup, zamanın çoğunun yanıt beklemekle geçtiği LLM API çağrıları gibi I/O yoğun iş yükleri için faydalıdır.

# config/solid_queue.yml
production:
  workers:
    - queues: [llm_calls, external_apis]
      fibers: 100
      polling_interval: 0.5

100 fiber ile, tek bir süreçte minimum bellek yükü ile 100 eşzamanlı I/O yoğun görev çalıştırılabilmektedir. Bu, önemli ölçüde daha fazla bellek tüketecek ve GVL (Global VM Lock) üzerinde çekişmeyle karşılaşacak 100 iş parçacığıyla olumlu bir şekilde karşılaştırılmaktadır.

Fiber modu, Rails'in fiber izolasyonu için yapılandırılmasını gerektirmektedir:

# config/application.rb
config.active_support.isolation_level = :fiber

CPU yoğun görevler iş parçacıklarını kullanmaya devam etmelidir, çünkü fiberlar iş I/O'ya geçiş yapmadığında hiçbir fayda sağlamamaktadır.

Rails 8.1'de Active Job Continuations

Rails 8.1, uzun süren görevlerin kontrol noktalarından duraklatılmasına ve devam ettirilmesine olanak tanıyan Active Job Continuations'ı tanıtmıştır. Bu, dağıtımlar veya konteyner yeniden başlatmaları nedeniyle kesintiye uğradığında görevlerin sıfırdan yeniden başlaması sorununu çözmektedir.

# app/jobs/process_import_job.rb
class ProcessImportJob < ApplicationJob
  include ActiveJob::Continuable

  def perform(import_id)
    @import = Import.find(import_id)

    step :validate do
      @import.validate!
    end

    step :process_records do |step|
      @import.records.find_each(start: step.cursor) do |record|
        record.process
        step.advance!(from: record.id)
      end
    end

    step :finalize do
      @import.mark_complete!
    end
  end
end

step metodu ayrı aşamaları tanımlamaktadır. Görev kesintiye uğrarsa, son tamamlanan adımdan devam etmektedir. Bir adım içinde step.cursor ilerlemeyi izlemektedir: step.advance!(from: record.id) imleç konumunu kaydetmektedir. Devam ettirildiğinde, find_each(start: step.cursor) işlemenin kaldığı yerden devam etmektedir.

İmleç herhangi bir serileştirilebilir değer olabilmektedir. İç içe döngüler için bir dizi kullanılabilmektedir:

step :process_nested, start: [0, 0] do |step|
  Account.find_each(start: step.cursor[0]) do |account|
    account.records.find_each(start: step.cursor[1]) do |record|
      record.process
      step.set!([account.id, record.id + 1])
    end
    step.set!([account.id + 1, 0])
  end
end

Cron Olmadan Tekrarlayan Görevler

Solid Queue, cron tabanlı zamanlamayı yerleşik bir zamanlayıcı ile değiştirmektedir. Tekrarlayan görevler bir YAML yapılandırma dosyasında tanımlanır ve zamanlayıcı süreci tarafından yönetilmektedir.

# config/recurring.yml
production:
  cleanup_expired_sessions:
    class: CleanupExpiredSessionsJob
    schedule: every 6 hours
  daily_report:
    class: DailyReportJob
    schedule: every day at 6am
    queue: reports
  weekly_digest:
    class: WeeklyDigestJob
    schedule: every Monday at 9am

Zamanlayıcı süreci bu dosyayı okuyarak tanımlanan aralıklarda uygun görevleri kuyruğa eklemektedir. Cron'un aksine, aynı süreç denetleyicisi içinde çalışır ve aynı veritabanı bağlantısını paylaşmaktadır. Saat dilimi desteği Solid Queue 1.5.0'da eklenmiştir.

Puma Entegrasyonu ile Dağıtım

Rails 8, Kamal ile birlikte Solid Queue için sıfır yapılandırmalı dağıtım sunmaktadır. SOLID_QUEUE_IN_PUMA=1 ortam değişkeni, Puma'ya Solid Queue süreçlerini web sunucusuyla birlikte başlatıp yönetmesini söylemektedir.

# config/puma.rb (Rails 8 default)
plugin :solid_queue if ENV["SOLID_QUEUE_IN_PUMA"]

Bu tek süreçli dağıtım modeli konteyner orkestrasyonunu basitleştirmektedir. Tek bir Docker imajı hem web sunucusunu hem de görev işleyicilerini çalıştırarak küçük ve orta ölçekli uygulamalar için operasyonel yükü azaltmaktadır.

Solid Cache: Ölçeklenen Veritabanı Destekli Önbellekleme

Solid Cache, modern SSD performansından yararlanarak Redis ve Memcached'i varsayılan önbellek deposu olarak değiştiren veritabanı destekli bir ActiveSupport::Cache::Store uygulamasıdır. Temel varsayım şudur: SSD'ler okuma işlemlerinde RAM'den yalnızca marjinal olarak yavaştır, ancak maliyetin çok küçük bir bölümüyle katbekat daha fazla depolama alanı sunmaktadır. Solid Cache, Basecamp'te 60 günlük saklama süresiyle 10 TB işleyerek üretimde çalışmakta ve P95 render sürelerini yarıya indirmektedir.

Solid Cache, LRU (Least Recently Used) yerine FIFO (First In, First Out) sona erme stratejisi kullanmaktadır. FIFO teorik olarak daha az verimli olsa da, çok daha büyük depolama kapasitesi bu farkı telafi etmektedir — girişler çok daha uzun süre önbellekte kalarak genel olarak önbellek kaçırma oranını düşürmektedir.

# config/environments/production.rb
config.cache_store = :solid_cache_store

# config/solid_cache.yml
production:
  databases:
    - cache
  store_options:
    max_age: 604800        # 1 week in seconds
    max_size: 256           # Max entry size in KB
    namespace: "app_v1"
    expiry_batch_size: 100  # Entries cleaned per expiry cycle

Önbellek Mimarisi ve Sona Erme Mekanizması

Solid Cache, yazma işlemlerini dahili bir sayaç ile takip etmektedir. Sayaç yapılandırılmış expiry_batch_size değerinin %50'sine ulaştığında, süresi dolmuş girişleri temizleyen bir arka plan görevi tetiklenmektedir. Bu amorti edilmiş yaklaşım, bellek kısıtlı Redis örneklerinde LRU tahliyesi sırasında oluşabilen durdur-ve-temizle (stop-the-world) duraklamalarını önlemektedir.

solid_cache_entries tablosu tüm önbellek verilerini saklamaktadır:

# db/cache_schema.rb (generated by installer)
create_table :solid_cache_entries do |t|
  t.binary :key, null: false, limit: 1024
  t.binary :value, null: false, limit: 262144  # 256 KB default
  t.datetime :created_at, null: false
  t.index :key, unique: true
  t.index :created_at  # For FIFO expiry
end

Varsayılan olarak bu tablodan okuma ve yazma, uygulamanın geri kalanıyla aynı bağlantı havuzunu kullanmaktadır. Yoğun trafikli uygulamalarda, önbellek verisi için ayrı bir veritabanı yapılandırmak, önbellek işlemlerinin birincil veritabanı performansını etkilemesini önlemektedir.

Önbellek İçin Ayrı Veritabanı Yapılandırması

Solid Cache'i özel bir veritabanında izole etmek basit bir işlemdir ve yoğun önbellek trafiği üreten üretim iş yükleri için önerilmektedir.

# config/database.yml
production:
  primary:
    <<: *default
    database: myapp_production
  cache:
    <<: *default
    database: myapp_cache_production
    migrations_paths: db/cache_migrate

Bu ayrım, milyonlarca önbellek yazma işleminin birincil veritabanının WAL'ını (Write-Ahead Log) şişirmemesini veya uygulama sorgularıyla bağlantı havuzu slotları için rekabet etmemesini sağlamaktadır.

Parçalama (Sharding) ve Şifreleme

Solid Cache, yükü dağıtmak için önbellek verilerinin birden fazla veritabanına parçalanmasını desteklemektedir. Ayrıca şifreli öznitelikleri de desteklemektedir — önbellek verileri durağan halde şifreli kalır, bu da hassas bilgileri işleyen uygulamalar için bir uyumluluk gerekliliğidir.

# config/solid_cache.yml
production:
  databases:
    - cache_shard_1
    - cache_shard_2
    - cache_shard_3
  store_options:
    max_age: 1209600  # 2 weeks

Girişler, önbellek anahtarı üzerinde tutarlı karma (consistent hashing) kullanılarak parçalar arasında dağıtılmaktadır. Parça ekleme veya kaldırma, girişler yeniden dağıtılırken geçici olarak önbellek kaçırmalarını artırır ancak veri kaybına yol açmamaktadır.

Mission Control Jobs ile İzleme

Mission Control Jobs, Solid Queue görevlerini incelemek ve yönetmek için bir web panosu sağlamaktadır. Montajlanmış bir Rails motoru aracılığıyla worker'ları, kuyrukları ve görev durumlarını (devam eden, tamamlanan, engellenen, başarısız) görüntülemektedir.

# config/routes.rb
Rails.application.routes.draw do
  mount MissionControl::Jobs::Engine, at: "/jobs"
end

# Gemfile
gem "mission_control-jobs", ">= 1.0.1"

Mission Control ayrıca başarısız görevler üzerinde toplu işlemler için bir konsol API'si sunmaktadır:

# Rails console
ActiveJob.jobs.failed.where(job_class: "ApiSyncJob").retry_all
ActiveJob.jobs.failed.where(job_class: "BrokenJob").discard_all

Bu programatik erişim, büyük ölçekli görev başarısızlıklarını bir panoda manuel tıklama yapmadan yönetmek için vazgeçilmezdir.

Kaynaklar

• Rails 8.0 Release Notes — Solid Queue ve Solid Cache varsayılanları için resmi belgeler
• Solid Queue GitHub Releases — Yığınlar (v1.7.0), fiber modu (v1.6.0) ve continuations desteği (v1.2.0) için değişiklik günlüğü
• Active Job Continuations PR — Rails 8.1 uygulama detayları
• Introducing Solid Queue (37signals) — Tasarım gerekçesi ve HEY'deki üretim kullanımı

Önemli Teknik Mülakat Soruları

Rails 8 mülakatları giderek artan bir şekilde Solid yığınına odaklanmaktadır. En sık karşılaşılan sorular ve beklenen yanıt derinliği aşağıda sunulmaktadır.

S: Solid Queue, Redis olmadan eşzamanlı görev işlemeyi nasıl sağlıyor? Solid Queue, FOR UPDATE SKIP LOCKED SQL yan tümcesini kullanmaktadır. Bu, birden fazla worker'ın aynı tabloyu birbirini engellemeden sorgulamasına olanak tanımaktadır. Her worker bir grup satırı kilitler, işler ve yürütme kayıtlarını siler. Diğer worker'lar zaten kilitli satırları atlayarak farklı görevleri talep etmektedir.

S: İşlemsel kuyruğa alma hangi sorunu çözüyor? Görevlerin, onları tetikleyen veritabanı işlemi tamamlanmadan önce yürütülmesini önlemektedir. Bu mekanizma olmadan bir görev, geri alınmış bir kaydı referans alarak ActiveRecord::RecordNotFound hatasına neden olabilmektedir.

S: Solid Cache neden LRU yerine FIFO kullanıyor? FIFO, veritabanında uygulanması daha basittir ve her okumada erişim zaman damgalarını güncelleme kaynaklı yazma yükünü ortadan kaldırmaktadır. Bu ödünleşim SSD kapasitesiyle telafi edilmektedir — girişler daha uzun süre yaşar, bu nedenle daha az optimal tahliye stratejisine rağmen isabet oranı yüksek kalmaktadır.

S: Solid Queue'da görev yığınları nasıl çalışıyor? SolidQueue::Batch.enqueue bloğu içinde kuyruğa alınan görevler birlikte izlenmektedir. Yığın, tüm görevler tamamlandığında on_finish, hepsi başarılı olursa on_success, herhangi biri başarısız olursa on_failure tetiklemektedir. Bu, son adımın tüm parçaların tamamlanmasına bağlı olduğu toplu içe aktarmalar gibi iş akışlarını mümkün kılmaktadır.

S: Active Job Continuations nedir ve ne zaman kullanılmalıdır? Continuations, uzun süren görevlerin ilerlemelerini kontrol noktası olarak kaydetmesine ve kesinti sonrası devam etmesine olanak tanımaktadır. İçe aktarmalar veya toplu güncellemeler gibi büyük veri setlerini işleyen görevler için kullanılmalıdır; her dağıtımda sıfırdan başlamak önemli miktarda zaman ve kaynak israfına neden olacaktır.

S: Bir uygulama ne zaman Solid yığını yerine Redis kullanmalı? Redis, dakikada 10.000'den fazla görev işleyen uygulamalar, milisaniye altı önbellek okumaları gerektiren iş yükleri veya zaten Redis'i başka amaçlarla (Pub/Sub, hız sınırlama, oturum depolama) kullanan uygulamalar için üstün olmaya devam etmektedir. Solid yığını, en yüksek verimi değil basitliği hedeflemektedir.

Bu soruları ve daha fazlasını SharpSkill'in ActiveJob ve Arka Plan Görevleri modülünde ve Önbellekleme Stratejileri modülünde pratik yaparak hazırlanmak mümkündür.

Rails 8'de Solid Queue ve Solid Cache Hakkında Hatırlanması Gerekenler

• Solid Queue, Redis tabanlı görev kuyruklarını veritabanı destekli bir çözümle değiştirmekte ve eşzamanlı işleme için FOR UPDATE SKIP LOCKED kullanmaktadır
• İşlemsel kuyruğa alma, veritabanı yazmaları ile görev yürütme arasındaki yarış koşullarını ortadan kaldırmaktadır — Redis'in sağlayamadığı bir garanti
• Görev yığınları (v1.7.0), daha önce Sidekiq Pro özelliği olan tamamlanma geri çağrılarıyla gruplu işlemleri mümkün kılmaktadır
• Fiber yürütme modu (v1.6.0), LLM API çağrıları gibi I/O yoğun iş yükleri için verimi artırmaktadır
• Active Job Continuations (Rails 8.1), uzun süren görevlerin kontrol noktası oluşturmasına ve kesinti sonrası devam etmesine olanak tanımaktadır
• Yerleşik eşzamanlılık kontrolleri, tekrarlayan görevler ve Puma entegrasyonu Solid Queue ile ek maliyet olmadan sunulmaktadır
• Solid Cache, isteğe bağlı parçalama ve şifreleme ile SSD destekli FIFO önbellekleme kullanarak Memcached ve Redis'i altyapı yığınından çıkarmaktadır
• Solid Cache için ayrı veritabanı yapılandırması, önbellek işlemlerinin birincil veritabanı performansını etkilemesini önlemektedir
• Mission Control Jobs, web panosu ve konsol API'si aracılığıyla üretim izleme ve toplu görev yönetimi sağlamaktadır
• 2026'da çoğu Rails 8 uygulaması için Solid yığını önerilen varsayılan seçenektir — Redis yalnızca dakikada 10.000 görevi aşan yüksek verimlilik gerektiren uç durumlar için tercih olarak kalmaktadır