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

> Solid Queue ve Solid Cache, Rails 8'de Redis bağımlılığını ortadan kaldırıyor. Mimari yapı, yapılandırma, eşzamanlılık kontrolleri ve 2026 teknik mülakat soruları hakkında kapsamlı rehber.

- Published: 2026-05-13
- Updated: 2026-05-13
- Author: Anthony Fillion-Maillet
- Tags: ruby-on-rails, solid-queue, solid-cache, rails-8, teknik-mulakat
- Reading time: 12 min

---

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 Üçlüsü**
>
> Rails 8, varsayılan olarak üç veritabanı destekli bileşen sunmaktadır: Solid Queue (arka plan görevleri), Solid Cache (önbellekleme) ve Solid Cable (WebSocket). Bu üçlü birlikte çalışarak çoğu Rails uygulamasından Redis bağımlılığını kaldırmaktadır. Bu konu, Rails 8 teknik mülakatlarında sıkça karşılaşılan bir alan olmaya devam etmektedir.

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

```ruby
# 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.

```ruby
# 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.

```ruby
# 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.

> **Mülakat İpucu**
>
> Rails 8 mülakatlarında sıkça sorulan bir soru, Solid Queue ile Sidekiq arasındaki karşılaştırmayı hedeflemektedir. Temel ayrım: Solid Queue, işlemsel garantiler ve yerleşik eşzamanlılık kontrolleri sunmaktadır — ücretsiz olarak. Sidekiq, Redis'in bellek içi çalışması sayesinde yüksek hacimli iş yüklerinde (dakikada 10.000+ görev) ham verimlilik açısından öne çıkmaktadır. Uygulamaların %95'i için Solid Queue yeterli performansı sağlamaktadır.

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

```ruby
# 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](https://kamal-deploy.org/) 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.

```ruby
# 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.

```ruby
# 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:

```ruby
# 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.

```yaml
# 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.

> **Üretim Ortamı Uyarısı**
>
> Ayrı bir veritabanı olmadan, Solid Cache okuma ve yazma işlemleri kapsayıcı ActiveRecord işlemlerine dahil olmaktadır. Bu durum, uzun süren bir işlemin önbellek girişlerini onaylanmamış durumda tutması anlamına gelmektedir. Üretim uygulamaları için mutlaka ayrılmış bir önbellek veritabanı yapılandırılmalıdı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](https://guides.rubyonrails.org/active_record_encryption.html) de desteklemektedir — önbellek verileri durağan halde şifreli kalır, bu da hassas bilgileri işleyen uygulamalar için bir uyumluluk gerekliliğidir.

```ruby
# 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](https://github.com/rails/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.

```ruby
# 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:

```ruby
# 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](/technologies/ruby-on-rails/interview-questions/active-job-background-jobs) ve [Önbellekleme Stratejileri modülünde](/technologies/ruby-on-rails/interview-questions/caching-strategies) 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

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/tr/blog/ruby-on-rails/solid-queue-solid-cache-rails-8-guide