Solid Queue e Solid Cache no Rails 8: Guia completo para entrevistas técnicas 2026

Solid Queue e Solid Cache representam a mudança de infraestrutura mais significativa da história do Rails. Ambos são entregues como padrão no Rails 8, substituindo o Redis para jobs em segundo plano e cache por alternativas baseadas em banco de dados que eliminam uma camada inteira de complexidade operacional.

Como o Solid Queue substitui backends de jobs baseados em Redis

O Solid Queue é um backend de Active Job baseado em banco de dados que armazena os jobs diretamente no PostgreSQL, MySQL ou SQLite. O mecanismo-chave é o FOR UPDATE SKIP LOCKED — um recurso SQL disponível no PostgreSQL 9.5+ e MySQL 8+ que transforma uma tabela relacional comum em uma fila de trabalho concorrente sem bloqueios.

A arquitetura é composta por três componentes:

• Workers: consultam a tabela solid_queue_ready_executions e reservam jobs usando SKIP LOCKED
• Dispatchers: movem jobs agendados de solid_queue_scheduled_executions para a tabela de prontos quando chega o momento de execução
• Schedulers: gerenciam tarefas recorrentes definidas na configuração

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

Essa configuração executa dois processos worker com 5 threads cada, consultando o banco a cada 100 ms. O dispatcher verifica os jobs agendados a cada segundo em lotes de 500.

Enfileiramento transacional no Rails 8

Um dos argumentos mais fortes a favor do Solid Queue em relação aos backends baseados em Redis é o enfileiramento transacional. Quando um job é enfileirado dentro de uma transação de banco de dados, ele só se torna visível após o commit da transação. Backends baseados em Redis não conseguem oferecer essa garantia — um job pode ser executado antes que a transação que o criou termine, referenciando registros que ainda não existem.

# 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

Com enqueue_after_transaction_commit habilitado, o job é adiado até que a transação que o envolve seja bem-sucedida. Se a transação sofrer rollback, o job nunca é enfileirado. Isso elimina toda uma classe de condições de corrida que afetam filas baseadas em Redis.

Controles de concorrência e filas com prioridade

O Solid Queue oferece controles de concorrência nativos que o Sidekiq só disponibiliza em sua versão Enterprise paga. A opção concurrency_limit restringe quantos jobs de um determinado tipo podem ser executados 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

Essa configuração garante que no máximo 3 jobs de sincronização de API sejam executados simultaneamente por conta, prevenindo violações de rate limit sem coordenação externa. Os jobs bloqueados são armazenados em solid_queue_blocked_executions e liberados automaticamente quando um slot fica disponível.

A prioridade funciona em dois níveis: prioridade numérica por job (número menor = prioridade mais alta) e ordenação de filas na configuração do worker. Ambos podem ser combinados para controle granular da ordem de execução.

Jobs recorrentes sem cron

O Solid Queue substitui o agendamento baseado em cron por um scheduler integrado. As tarefas recorrentes são definidas em um arquivo de configuração YAML e gerenciadas pelo 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

O processo scheduler lê esse arquivo e enfileira os jobs apropriados nos intervalos definidos. Diferente do cron, ele é executado dentro do mesmo supervisor de processos e compartilha a mesma conexão com o banco de dados.

Deploy com integração Puma

O Rails 8 com Kamal oferece deploy sem configuração para o Solid Queue. A variável SOLID_QUEUE_IN_PUMA=1 instrui o Puma a fazer fork e supervisionar os processos do Solid Queue junto ao servidor web.

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

Esse modelo de deploy em processo único simplifica a orquestração de contêineres. Uma única imagem Docker executa tanto o servidor web quanto os processadores de jobs, reduzindo a sobrecarga operacional para aplicações de pequeno e médio porte.

Solid Cache: cache baseado em banco de dados que escala

O Solid Cache é um ActiveSupport::Cache::Store baseado em banco de dados que aproveita o desempenho dos SSDs modernos para substituir Redis e Memcached como armazenamento de cache padrão. A premissa: SSDs são apenas marginalmente mais lentos que a RAM para operações de leitura, mas oferecem ordens de magnitude a mais de armazenamento por uma fração do custo.

O Solid Cache utiliza uma estratégia de expiração FIFO (First In, First Out) em vez de LRU (Least Recently Used). Embora o FIFO seja teoricamente menos eficiente, a capacidade de armazenamento vastamente superior compensa — as entradas permanecem em cache por muito mais tempo, reduzindo os cache misses no geral.

# 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

Arquitetura do cache e mecanismo de expiração

O Solid Cache rastreia as escritas por meio de um contador interno. Quando o contador atinge 50% do expiry_batch_size configurado, uma tarefa em segundo plano é acionada para limpar as entradas expiradas. Essa abordagem amortizada evita as pausas do tipo stop-the-world que podem ocorrer com a evicção LRU em instâncias Redis com memória limitada.

A tabela solid_cache_entries armazena todos os dados em cache:

# 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

A leitura e escrita nessa tabela utilizam por padrão o mesmo pool de conexões do restante da aplicação. Para aplicações de alto tráfego, configurar um banco de dados separado para os dados de cache evita que as operações de cache impactem o desempenho do banco principal.

Configuração de banco de dados separado para o cache

Isolar o Solid Cache em um banco de dados dedicado é simples e recomendado para ambientes de produção que geram tráfego de cache significativo.

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

Essa separação garante que milhões de operações de escrita de cache não inflem o WAL (Write-Ahead Log) do banco primário nem disputem slots do pool de conexões com as queries da aplicação.

Sharding e criptografia

O Solid Cache suporta sharding dos dados em cache através de múltiplos bancos de dados para distribuir a carga. Também suporta atributos criptografados — os dados em cache permanecem criptografados em repouso, um requisito de conformidade para aplicações que lidam com informações sensíveis.

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

As entradas são distribuídas entre os shards usando hashing consistente na chave de cache. Adicionar ou remover shards causa um aumento temporário nos cache misses enquanto as entradas são redistribuídas, mas nenhuma perda de dados ocorre.

Monitoramento com Mission Control Jobs

Mission Control Jobs fornece um painel web para inspecionar e gerenciar os jobs do Solid Queue. Exibe os workers, filas e estados dos jobs (em progresso, finalizados, bloqueados, falhos) por meio de uma engine Rails montada.

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

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

O Mission Control também expõe uma API de console para operações em massa sobre jobs falhos:

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

Esse acesso programático é essencial para lidar com falhas de jobs em larga escala sem a necessidade de navegar manualmente por um painel de controle.

Perguntas técnicas essenciais para entrevistas

As entrevistas sobre Rails 8 focam cada vez mais no stack Solid. A seguir, as perguntas mais frequentes e a profundidade de resposta esperada.

P: Como o Solid Queue consegue processar jobs de forma concorrente sem Redis? O Solid Queue utiliza FOR UPDATE SKIP LOCKED, uma cláusula SQL que permite a múltiplos workers consultarem a mesma tabela sem bloquearem uns aos outros. Cada worker bloqueia um lote de linhas, as processa e deleta os registros de execução. Os demais workers ignoram as linhas já bloqueadas e reservam jobs diferentes.

P: Que problema o enfileiramento transacional resolve? Ele impede que jobs sejam executados antes que a transação de banco de dados que os originou tenha sido commitada. Sem isso, um job poderia referenciar um registro que sofreu rollback, causando erros ActiveRecord::RecordNotFound.

P: Por que o Solid Cache usa FIFO em vez de LRU? O FIFO é mais simples de implementar em banco de dados e evita a amplificação de escrita causada pela atualização de timestamps de acesso a cada leitura. Essa troca é compensada pela capacidade dos SSDs — as entradas vivem mais tempo, então a taxa de acertos permanece alta apesar da estratégia de evicção menos otimizada.

P: Quando uma aplicação ainda deve usar Redis em vez do stack Solid? O Redis continua superior para aplicações que processam mais de 10.000 jobs por minuto, cargas que exigem leituras de cache abaixo do milissegundo, ou aplicações que já utilizam Redis para outros fins (Pub/Sub, rate limiting, armazenamento de sessões). O stack Solid visa a simplicidade, não o throughput máximo.

Essas perguntas e muitas outras podem ser praticadas nos módulos ActiveJob e jobs em segundo plano e Estratégias de cache do SharpSkill.

Conclusão

• O Solid Queue substitui filas de jobs baseadas em Redis por uma solução baseada em banco de dados usando FOR UPDATE SKIP LOCKED para processamento concorrente
• O enfileiramento transacional elimina condições de corrida entre escritas no banco e execução de jobs — uma garantia que o Redis não consegue oferecer
• Controles de concorrência integrados, jobs recorrentes e integração com Puma são incluídos no Solid Queue sem custo adicional
• O Solid Cache utiliza cache FIFO baseado em SSD com sharding e criptografia opcionais, removendo Memcached e Redis da pilha de infraestrutura
• A configuração de banco de dados separado para o Solid Cache impede que operações de cache impactem o desempenho do banco principal
• O Mission Control Jobs fornece monitoramento em produção e gerenciamento em massa de jobs por meio de um painel web e API de console
• Para a maioria das aplicações Rails 8 em 2026, o stack Solid é a escolha padrão recomendada — o Redis permanece como opção apenas para cenários de alto throughput que excedem 10.000 jobs por minuto