Solid Queue e Solid Cache in Rails 8: Guida Completa per Colloqui Tecnici 2026

Solid Queue e Solid Cache rappresentano il cambiamento infrastrutturale più significativo nella storia di Rails. Entrambi i componenti sono inclusi come predefiniti in Rails 8, sostituendo Redis per i job in background e il caching con alternative database-backed che eliminano un intero livello di complessità operativa.

Come Solid Queue sostituisce i backend job basati su Redis

Solid Queue è un backend Active Job database-backed che memorizza i job direttamente in PostgreSQL, MySQL o SQLite. Il meccanismo chiave è FOR UPDATE SKIP LOCKED — una funzionalità SQL disponibile a partire da PostgreSQL 9.5+ e MySQL 8+ che trasforma una normale tabella del database in una coda di job concorrente senza blocchi.

L'architettura si compone di tre elementi:

• Worker interrogano solid_queue_ready_executions e acquisiscono i job tramite SKIP LOCKED
• Dispatcher spostano i job pianificati da solid_queue_scheduled_executions alla tabella dei job pronti quando il loro orario di esecuzione è raggiunto
• Scheduler gestiscono le attività ricorrenti definite nella configurazione

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

Questa configurazione avvia due processi worker con 5 thread ciascuno, che effettuano il polling ogni 100 ms. Il dispatcher verifica i job pianificati ogni secondo in batch da 500.

Accodamento transazionale dei job in Rails 8

Uno degli argomenti più forti a favore di Solid Queue rispetto ai backend basati su Redis è l'accodamento transazionale. Quando un job viene accodato all'interno di una transazione del database, diventa visibile solo dopo il commit della transazione. I backend basati su Redis non possono offrire questa garanzia — un job potrebbe essere eseguito prima che la transazione che lo ha generato sia completata, facendo riferimento a record non ancora esistenti.

# 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)
    # Il job viene accodato solo dopo il commit della transazione CREATE
    # Nessun rischio che il job venga eseguito prima della creazione del record utente
  end
end

Con enqueue_after_transaction_commit attivato, il job viene differito fino al completamento con successo della transazione che lo contiene. Se la transazione viene annullata con rollback, il job non viene mai accodato. Questo elimina un'intera classe di race condition che affligge le code basate su Redis.

Controlli di concorrenza e code prioritarie

Solid Queue fornisce controlli di concorrenza integrati che Sidekiq offre solo nella versione Enterprise a pagamento. L'opzione concurrency_limit limita il numero di job di un determinato tipo che possono essere eseguiti simultaneamente.

# 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

Questo garantisce che al massimo 3 job di sincronizzazione API vengano eseguiti contemporaneamente per account, prevenendo violazioni dei limiti di frequenza senza coordinamento esterno. I job bloccati vengono memorizzati in solid_queue_blocked_executions e rilasciati automaticamente quando uno slot si libera.

La priorità funziona su due livelli: priorità numerica per job (numero inferiore = priorità superiore) e ordinamento delle code nella configurazione del worker. Entrambi i livelli possono essere combinati per un controllo granulare sull'ordine di esecuzione dei job.

Job ricorrenti senza Cron

Solid Queue sostituisce la pianificazione basata su cron con uno scheduler integrato. Le attività ricorrenti vengono definite in un file di configurazione YAML e gestite dal processo scheduler.

# 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

Il processo scheduler legge questo file e accoda i job appropriati agli intervalli definiti. A differenza di cron, opera all'interno dello stesso supervisore di processi e condivide la stessa connessione al database.

Deployment con integrazione Puma

Rails 8 con Kamal offre un deployment a configurazione zero per Solid Queue. L'impostazione SOLID_QUEUE_IN_PUMA=1 indica a Puma di effettuare il fork e supervisionare i processi Solid Queue insieme al web server.

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

Questo modello di deployment a processo singolo semplifica l'orchestrazione dei container. Una singola immagine Docker esegue sia il web server che i processori di job, riducendo il carico operativo per applicazioni di piccole e medie dimensioni.

Solid Cache: caching database-backed scalabile

Solid Cache è un ActiveSupport::Cache::Store database-backed che sfrutta le prestazioni degli SSD moderni per sostituire Redis e Memcached come cache store predefinito. La premessa: gli SSD sono solo marginalmente più lenti della RAM per le operazioni di lettura, ma offrono ordini di grandezza in più di spazio di archiviazione a una frazione del costo.

Solid Cache utilizza una strategia di espulsione FIFO (First In, First Out) anziché LRU (Least Recently Used). Sebbene FIFO sia teoricamente meno efficiente, la capacità di archiviazione enormemente superiore compensa — le voci rimangono nella cache molto più a lungo, riducendo complessivamente i cache miss.

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

# config/solid_cache.yml
production:
  databases:
    - cache
  store_options:
    max_age: 604800        # 1 settimana in secondi
    max_size: 256           # Dimensione max per voce in KB
    namespace: "app_v1"
    expiry_batch_size: 100  # Voci ripulite per ciclo di scadenza

Architettura della cache e meccanismo di espulsione

Solid Cache traccia le scritture utilizzando un contatore interno. Quando il contatore raggiunge il 50% dell'expiry_batch_size configurato, viene attivata un'attività in background per ripulire le voci scadute. Questo approccio ammortizzato evita le pause stop-the-world che possono verificarsi con l'espulsione LRU in istanze Redis con memoria limitata.

La tabella solid_cache_entries memorizza tutti i dati nella cache:

# db/cache_schema.rb (generato dall'installer)
create_table :solid_cache_entries do |t|
  t.binary :key, null: false, limit: 1024
  t.binary :value, null: false, limit: 262144  # 256 KB predefinito
  t.datetime :created_at, null: false
  t.index :key, unique: true
  t.index :created_at  # Per espulsione FIFO
end

Le operazioni di lettura e scrittura su questa tabella utilizzano lo stesso connection pool del resto dell'applicazione per impostazione predefinita. Per applicazioni ad alto traffico, la configurazione di un database separato per i dati della cache impedisce che le operazioni di cache impattino sulle prestazioni del database primario.

Configurazione di un database separato per la cache

Isolare Solid Cache su un database dedicato è semplice e raccomandato per i carichi di produzione che generano traffico cache significativo.

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

Questa separazione garantisce che milioni di operazioni di scrittura nella cache non gonfino il WAL (Write-Ahead Log) del database primario né competano per gli slot del connection pool con le query applicative.

Sharding e crittografia

Solid Cache supporta lo sharding dei dati nella cache su più database per distribuire il carico. Supporta inoltre gli attributi crittografati — i dati nella cache rimangono crittografati a riposo, un requisito di conformità per le applicazioni che gestiscono informazioni sensibili.

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

Le voci vengono distribuite tra gli shard utilizzando il consistent hashing sulla chiave della cache. L'aggiunta o la rimozione di shard causa un aumento temporaneo dei cache miss man mano che le voci vengono ridistribuite, ma non si verifica alcuna perdita di dati.

Monitoraggio con Mission Control Jobs

Mission Control Jobs fornisce una dashboard web per ispezionare e gestire i job di Solid Queue. Visualizza worker, code e stati dei job (in corso, completati, bloccati, falliti) attraverso un engine Rails montato.

# 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 espone anche un'API da console per operazioni di massa sui job falliti:

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

Questo accesso programmatico è essenziale per gestire guasti di job su larga scala senza dover navigare manualmente in una dashboard.

Domande chiave per i colloqui tecnici

I colloqui su Rails 8 si concentrano sempre di più sullo stack Solid. Di seguito le domande più frequenti, con il livello di approfondimento atteso nelle risposte.

D: Come fa Solid Queue a ottenere l'elaborazione concorrente dei job senza Redis? Solid Queue utilizza FOR UPDATE SKIP LOCKED, una clausola SQL che consente a più worker di interrogare la stessa tabella senza bloccarsi a vicenda. Ogni worker blocca un batch di righe, le elabora e cancella i record di esecuzione. Gli altri worker saltano le righe già bloccate e acquisiscono job diversi.

D: Quale problema risolve l'accodamento transazionale? Impedisce che i job vengano eseguiti prima che la transazione del database che li ha generati abbia effettuato il commit. Senza questa garanzia, un job potrebbe fare riferimento a un record annullato con rollback, causando errori ActiveRecord::RecordNotFound.

D: Perché Solid Cache utilizza FIFO invece di LRU? FIFO è più semplice da implementare in un database ed evita l'amplificazione delle scritture dovuta all'aggiornamento dei timestamp di accesso a ogni lettura. Il compromesso è compensato dalla capacità degli SSD — le voci sopravvivono più a lungo, quindi il tasso di hit rimane elevato nonostante la strategia di espulsione meno ottimale.

D: Quando un'applicazione dovrebbe ancora utilizzare Redis anziché lo stack Solid? Redis rimane superiore per applicazioni che elaborano più di 10.000 job al minuto, per carichi che richiedono letture dalla cache inferiori al millisecondo, o per applicazioni che già utilizzano Redis per altri scopi (Pub/Sub, rate limiting, gestione delle sessioni). Lo stack Solid punta alla semplicità, non al throughput massimo.

Queste domande e molte altre sono disponibili per la pratica sul modulo ActiveJob e Job in Background di SharpSkill e sul modulo Strategie di Caching.

Conclusione

• Solid Queue sostituisce le code di job basate su Redis con una soluzione database-backed che utilizza FOR UPDATE SKIP LOCKED per l'elaborazione concorrente
• L'accodamento transazionale elimina le race condition tra le scritture nel database e l'esecuzione dei job — una garanzia che Redis non può fornire
• Controlli di concorrenza integrati, job ricorrenti e integrazione con Puma sono inclusi in Solid Queue senza costi aggiuntivi
• Solid Cache utilizza il caching FIFO su SSD con sharding e crittografia opzionali, rimuovendo Memcached e Redis dallo stack infrastrutturale
• La configurazione di un database separato per Solid Cache impedisce che le operazioni di cache impattino sulle prestazioni del database primario
• Mission Control Jobs offre monitoraggio in produzione e gestione massiva dei job tramite dashboard web e API da console
• Per la maggior parte delle applicazioni Rails 8 nel 2026, lo stack Solid è la scelta predefinita raccomandata — Redis resta l'opzione preferita solo per i casi limite ad alto throughput che superano i 10.000 job al minuto