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.

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.

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, 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.

Ö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: 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.

Sonuç

• 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
• 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