Solid Queue und Solid Cache in Rails 8: Umfassender Leitfaden für technische Vorstellungsgespräche 2026

Solid Queue und Solid Cache markieren den bedeutendsten Infrastrukturwandel in der Geschichte von Rails. Beide Komponenten sind seit Rails 8 als Standardlösungen integriert und ersetzen Redis für Hintergrund-Jobs und Caching durch datenbankgestützte Alternativen, die eine ganze Schicht operativer Komplexität eliminieren.

Wie Solid Queue Redis-basierte Job-Backends ersetzt

Solid Queue ist ein datenbankgestütztes Active-Job-Backend, das Jobs direkt in PostgreSQL, MySQL oder SQLite speichert. Der zentrale Mechanismus ist FOR UPDATE SKIP LOCKED, ein SQL-Feature, das ab PostgreSQL 9.5+ und MySQL 8+ verfügbar ist und eine reguläre Datenbanktabelle in eine nebenläufige Job-Warteschlange verwandelt, ohne Blockierungen zu verursachen.

Die Architektur besteht aus drei Komponenten:

• Workers fragen solid_queue_ready_executions ab und beanspruchen Jobs mittels SKIP LOCKED
• Dispatcher verschieben geplante Jobs von solid_queue_scheduled_executions in die Ready-Tabelle, sobald deren Ausführungszeit erreicht ist
• Scheduler verwalten wiederkehrende Aufgaben gemäß der Konfiguration

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

Diese Konfiguration startet zwei Worker-Prozesse mit jeweils 5 Threads, die alle 100 ms abfragen. Der Dispatcher prüft geplante Jobs jede Sekunde in Stapeln von 500.

Transaktionale Job-Einreihung in Rails 8

Eines der stärksten Argumente für Solid Queue gegenüber Redis-basierten Backends ist die transaktionale Einreihung. Wird ein Job innerhalb einer Datenbanktransaktion eingereiht, wird er erst nach dem Commit der Transaktion sichtbar. Redis-basierte Backends können diese Garantie nicht bieten: ein Job könnte ausgeführt werden, bevor die auslösende Transaktion abgeschlossen ist, und dabei auf Datensätze verweisen, die noch nicht existieren.

# 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 wird erst nach Commit der CREATE-Transaktion eingereiht
    # Kein Risiko, dass der Job vor dem Anlegen des User-Datensatzes läuft
  end
end

Mit aktiviertem enqueue_after_transaction_commit wird der Job bis zum erfolgreichen Abschluss der umgebenden Transaktion zurückgehalten. Wird die Transaktion zurückgerollt, wird der Job niemals eingereiht. Damit wird eine ganze Klasse von Race Conditions eliminiert, die Redis-gestützte Warteschlangen plagen.

Nebenläufigkeitssteuerung und Prioritätswarteschlangen

Solid Queue bietet integrierte Nebenläufigkeitskontrollen, die Sidekiq nur in der kostenpflichtigen Enterprise-Version anbietet. Die Option concurrency_limit beschränkt, wie viele Jobs eines bestimmten Typs gleichzeitig ausgeführt werden können.

# 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

Dies stellt sicher, dass höchstens 3 API-Sync-Jobs gleichzeitig pro Account laufen und Ratenlimit-Überschreitungen ohne externe Koordination verhindert werden. Blockierte Jobs werden in solid_queue_blocked_executions gespeichert und automatisch freigegeben, sobald ein Platz frei wird.

Priorität funktioniert auf zwei Ebenen: numerische Priorität pro Job (niedrigere Zahl = höhere Priorität) und Warteschlangen-Reihenfolge in der Worker-Konfiguration. Beide Ebenen lassen sich für eine feingranulare Steuerung der Job-Ausführungsreihenfolge kombinieren.

Job-Batches für gruppierte Operationen

Solid Queue 1.7.0 führte Job-Batches ein, mit denen Jobs als Gruppe zusammengefasst und verfolgt werden können. Dieses Feature ermöglicht Callbacks, wenn alle Jobs eines Batches abgeschlossen sind, ein Muster, das zuvor Sidekiq Pro erforderte.

# 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

Der Batch verfolgt alle Jobs, die innerhalb seines Blocks eingereiht werden. Wenn alle Jobs abgeschlossen sind, wird on_finish ausgelöst, unabhängig von Erfolg oder Misserfolg. Bei Erfolg aller Jobs wird on_success ausgelöst. Schlägt ein Job fehl, wird on_failure ausgelöst. Dies ermöglicht Workflows wie Import-Verarbeitung, bei denen ein finaler Schritt auf den Abschluss aller Teile warten muss.

Jobs, die außerhalb eines Batches erstellt, aber innerhalb eines solchen eingereiht werden, treten diesem Batch bei. Ein Batch ohne Jobs wird sofort abgeschlossen und löst seine Callbacks unmittelbar aus.

Fiber-Ausführungsmodus für I/O-lastige Workloads

Solid Queue 1.6.0 fügte die Fiber-basierte Worker-Ausführung mit dem Async-Gem hinzu. Dieser Modus führt Jobs auf Fibers statt auf Threads aus, was für I/O-lastige Workloads wie LLM-API-Aufrufe vorteilhaft ist, bei denen die meiste Zeit auf Antworten gewartet wird.

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

Mit 100 Fibers können 100 gleichzeitige I/O-lastige Jobs in einem einzigen Prozess mit minimalem Speicher-Overhead ausgeführt werden. Dies ist günstiger als 100 Threads, die deutlich mehr Speicher verbrauchen und mit Kontention am GVL (Global VM Lock) konfrontiert sind.

Der Fiber-Modus erfordert, dass Rails für Fiber-Isolation konfiguriert ist:

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

CPU-lastige Jobs sollten weiterhin Threads verwenden, da Fibers keinen Vorteil bieten, wenn die Arbeit nicht auf I/O wartet.

Active Job Continuations in Rails 8.1

Rails 8.1 führte Active Job Continuations ein, die es langlaufenden Jobs ermöglichen, an Checkpoints anzuhalten und fortzusetzen. Dies löst das Problem, dass Jobs bei Deployments oder Container-Neustarts von vorne beginnen müssen.

# 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

Die step-Methode definiert diskrete Phasen. Wird der Job unterbrochen, setzt er bei der letzten abgeschlossenen Phase fort. Innerhalb einer Phase verfolgt step.cursor den Fortschritt: step.advance!(from: record.id) speichert die Cursor-Position. Bei Wiederaufnahme setzt find_each(start: step.cursor) dort fort, wo die Verarbeitung unterbrochen wurde.

Der Cursor kann ein beliebiger serialisierbarer Wert sein. Für verschachtelte Schleifen wird ein Array verwendet:

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

Wiederkehrende Jobs ohne Cron

Solid Queue ersetzt cron-basierte Planung durch einen integrierten Scheduler. Wiederkehrende Aufgaben werden in einer YAML-Konfigurationsdatei definiert und vom Scheduler-Prozess verwaltet.

# 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

Der Scheduler-Prozess liest diese Datei und reiht die entsprechenden Jobs in den definierten Intervallen ein. Anders als Cron läuft er innerhalb desselben Prozess-Supervisors und teilt sich die gleiche Datenbankverbindung. Zeitzonen-Unterstützung wurde in Solid Queue 1.5.0 hinzugefügt.

Deployment mit Puma-Integration

Rails 8 mit Kamal bietet eine konfigurationsfreie Bereitstellung für Solid Queue. Die Umgebungsvariable SOLID_QUEUE_IN_PUMA=1 weist Puma an, Solid-Queue-Prozesse zusammen mit dem Webserver zu forken und zu überwachen.

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

Dieses Single-Process-Deployment-Modell vereinfacht die Container-Orchestrierung. Ein einziges Docker-Image betreibt sowohl den Webserver als auch die Job-Verarbeitung und reduziert den Betriebsaufwand für kleine bis mittlere Anwendungen.

Solid Cache: Datenbankgestütztes Caching mit Skalierbarkeit

Solid Cache ist ein datenbankgestützter ActiveSupport::Cache::Store, der die Leistung moderner SSDs nutzt, um Redis und Memcached als Standard-Cache-Speicher zu ersetzen. Die Prämisse: SSDs sind bei Lesevorgängen nur geringfügig langsamer als RAM, bieten jedoch um Größenordnungen mehr Speicherkapazität zu einem Bruchteil der Kosten. Solid Cache ist bei Basecamp im Produktionseinsatz mit 10 TB und 60-tägiger Aufbewahrung, was die P95-Renderzeiten halbiert hat.

Solid Cache verwendet eine FIFO-Verdrängungsstrategie (First In, First Out) anstelle von LRU (Least Recently Used). Obwohl FIFO theoretisch weniger effizient ist, kompensiert die deutlich größere Speicherkapazität: Einträge bleiben viel länger im Cache, was die Cache-Fehlquote insgesamt senkt.

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

# config/solid_cache.yml
production:
  databases:
    - cache
  store_options:
    max_age: 604800        # 1 Woche in Sekunden
    max_size: 256           # Max. Eintragsgröße in KB
    namespace: "app_v1"
    expiry_batch_size: 100  # Einträge pro Aufräumzyklus

Cache-Architektur und Verdrängungsmechanismus

Solid Cache verfolgt Schreibvorgänge über einen internen Zähler. Erreicht der Zähler 50 % der konfigurierten expiry_batch_size, wird eine Hintergrundaufgabe zur Bereinigung abgelaufener Einträge ausgelöst. Dieser amortisierte Ansatz vermeidet die Stop-the-World-Pausen, die bei LRU-Verdrängung in speicherbeschränkten Redis-Instanzen auftreten können.

Die Tabelle solid_cache_entries speichert alle zwischengespeicherten Daten:

# db/cache_schema.rb (vom Installer generiert)
create_table :solid_cache_entries do |t|
  t.binary :key, null: false, limit: 1024
  t.binary :value, null: false, limit: 262144  # 256 KB Standard
  t.datetime :created_at, null: false
  t.index :key, unique: true
  t.index :created_at  # Für FIFO-Verdrängung
end

Lese- und Schreibvorgänge auf diese Tabelle verwenden standardmäßig denselben Connection Pool wie die restliche Anwendung. Für stark frequentierte Anwendungen verhindert eine separate Datenbank für Cache-Daten, dass Cache-Operationen die Performance der Hauptdatenbank beeinträchtigen.

Separate Datenbankkonfiguration für den Cache

Die Isolation von Solid Cache auf einer dedizierten Datenbank ist unkompliziert und wird für Produktionsumgebungen mit signifikantem Cache-Verkehr empfohlen.

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

Diese Trennung stellt sicher, dass Millionen von Cache-Schreibvorgängen weder das WAL (Write-Ahead Log) der Hauptdatenbank aufblähen noch um Connection-Pool-Plätze mit Anwendungsabfragen konkurrieren.

Sharding und Verschlüsselung

Solid Cache unterstützt das Sharding von Cache-Daten über mehrere Datenbanken zur Lastverteilung. Zusätzlich werden verschlüsselte Attribute unterstützt, um zwischengespeicherte Daten im Ruhezustand zu verschlüsseln, eine Compliance-Anforderung für Anwendungen, die sensible Informationen verarbeiten.

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

Einträge werden mittels Consistent Hashing auf dem Cache-Schlüssel über die Shards verteilt. Das Hinzufügen oder Entfernen von Shards führt zu einem vorübergehenden Anstieg der Cache-Fehlquote, da Einträge neu verteilt werden, aber es gehen keine Daten verloren.

Monitoring mit Mission Control Jobs

Mission Control Jobs bietet ein Web-Dashboard zur Inspektion und Verwaltung von Solid-Queue-Jobs. Es zeigt Worker, Warteschlangen und Job-Zustände (laufend, abgeschlossen, blockiert, fehlgeschlagen) über eine eingebundene Rails-Engine an.

# 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 stellt auch eine Konsolen-API für Massenoperationen bei fehlgeschlagenen Jobs bereit:

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

Dieser programmatische Zugriff ist unerlässlich für die Behandlung großflächiger Job-Fehler, ohne sich manuell durch ein Dashboard klicken zu müssen.

Quellen

• Rails 8.0 Release Notes - Offizielle Dokumentation zu Solid Queue und Solid Cache als Standardkomponenten
• Solid Queue GitHub Releases - Changelog für Batches (v1.7.0), Fiber-Modus (v1.6.0) und Continuations-Unterstützung (v1.2.0)
• Active Job Continuations PR - Rails 8.1 Implementierungsdetails
• Introducing Solid Queue (37signals) - Design-Hintergrund und Produktionseinsatz bei HEY

Zentrale Fragen für technische Vorstellungsgespräche

In Interviews zu Rails 8 liegt der Fokus zunehmend auf dem Solid Stack. Die folgenden Fragen tauchen am häufigsten auf, zusammen mit der erwarteten Antworttiefe.

F: Wie erreicht Solid Queue nebenläufige Job-Verarbeitung ohne Redis? Solid Queue verwendet FOR UPDATE SKIP LOCKED, eine SQL-Klausel, die mehreren Workern erlaubt, dieselbe Tabelle abzufragen, ohne sich gegenseitig zu blockieren. Jeder Worker sperrt einen Stapel von Zeilen, verarbeitet diese und löscht die Ausführungsdatensätze. Andere Worker überspringen bereits gesperrte Zeilen und beanspruchen andere Jobs.

F: Welches Problem löst die transaktionale Einreihung? Sie verhindert, dass Jobs ausgeführt werden, bevor die Datenbanktransaktion, die sie ausgelöst hat, committed wurde. Ohne diese Garantie könnte ein Job auf einen Datensatz verweisen, der zurückgerollt wurde, was zu ActiveRecord::RecordNotFound-Fehlern führt.

F: Warum verwendet Solid Cache FIFO statt LRU? FIFO ist in einer Datenbank einfacher zu implementieren und vermeidet die Schreibverstärkung durch das Aktualisieren von Zugriffszeitstempeln bei jedem Lesevorgang. Der Nachteil wird durch die SSD-Kapazität ausgeglichen: Einträge leben länger, sodass die Trefferquote trotz der weniger optimalen Verdrängungsstrategie hoch bleibt.

F: Wie funktionieren Job-Batches in Solid Queue? Jobs, die innerhalb eines SolidQueue::Batch.enqueue-Blocks eingereiht werden, werden gemeinsam verfolgt. Der Batch löst on_finish aus, wenn alle Jobs abgeschlossen sind, on_success bei Erfolg aller Jobs oder on_failure bei Fehlschlag eines Jobs. Dies ermöglicht Workflows wie Batch-Imports, bei denen ein finaler Schritt vom Abschluss aller Teile abhängt.

F: Was sind Active Job Continuations und wann sollten sie verwendet werden? Continuations ermöglichen langlaufenden Jobs, ihren Fortschritt zu checkpointen und nach einer Unterbrechung fortzusetzen. Sie sollten für Jobs verwendet werden, die große Datensätze verarbeiten, etwa Imports oder Batch-Updates, bei denen ein Neustart von vorne bei jedem Deployment erhebliche Zeit und Ressourcen verschwenden würde.

F: Wann sollte eine Anwendung weiterhin Redis statt dem Solid Stack verwenden? Redis bleibt überlegen für Anwendungen, die mehr als 10.000 Jobs pro Minute verarbeiten, für Workloads, die Cache-Lesezeiten unter einer Millisekunde erfordern, oder für Anwendungen, die Redis bereits für andere Zwecke nutzen (Pub/Sub, Rate Limiting, Session-Speicherung). Der Solid Stack zielt auf Einfachheit, nicht auf maximalen Durchsatz.

Diese und weitere Fragen lassen sich auf SharpSkills Modul zu ActiveJob und Hintergrund-Jobs sowie dem Modul zu Caching-Strategien üben.

Was bei Solid Queue und Solid Cache in Rails 8 zu beachten ist

• Solid Queue ersetzt Redis-gestützte Job-Warteschlangen durch eine datenbankgestützte Lösung mit FOR UPDATE SKIP LOCKED für nebenläufige Verarbeitung
• Transaktionale Einreihung eliminiert Race Conditions zwischen Datenbankschreibvorgängen und Job-Ausführung, eine Garantie, die Redis nicht bieten kann
• Job-Batches (v1.7.0) ermöglichen gruppierte Operationen mit Abschluss-Callbacks, zuvor ein Sidekiq-Pro-Feature
• Der Fiber-Ausführungsmodus (v1.6.0) verbessert den Durchsatz für I/O-lastige Workloads wie LLM-API-Aufrufe
• Active Job Continuations (Rails 8.1) ermöglichen langlaufenden Jobs, Checkpoints zu setzen und nach einer Unterbrechung fortzusetzen
• Integrierte Nebenläufigkeitskontrollen, wiederkehrende Jobs und Puma-Integration sind ohne Zusatzkosten in Solid Queue enthalten
• Solid Cache nutzt SSD-gestütztes FIFO-Caching mit optionalem Sharding und Verschlüsselung und entfernt Memcached sowie Redis aus dem Infrastruktur-Stack
• Eine separate Datenbankkonfiguration für Solid Cache verhindert, dass Cache-Operationen die Performance der Hauptdatenbank beeinträchtigen
• Mission Control Jobs bietet Produktionsmonitoring und Massen-Job-Verwaltung über ein Web-Dashboard und eine Konsolen-API
• Für die meisten Rails-8-Anwendungen im Jahr 2026 ist der Solid Stack die empfohlene Standardwahl. Redis bleibt nur für Hochdurchsatz-Grenzfälle mit über 10.000 Jobs pro Minute die bevorzugte Option