Solid Queue y Solid Cache en Rails 8: Guía completa para entrevistas técnicas 2026

Solid Queue y Solid Cache representan el cambio de infraestructura más significativo en la historia de Rails. Ambos componentes se incluyen por defecto en Rails 8, reemplazando Redis para trabajos en segundo plano y almacenamiento en caché con alternativas respaldadas por base de datos que eliminan una capa completa de complejidad operacional.

Cómo Solid Queue reemplaza los backends de jobs basados en Redis

Solid Queue es un backend de Active Job respaldado por base de datos que almacena los jobs directamente en PostgreSQL, MySQL o SQLite. El mecanismo clave es FOR UPDATE SKIP LOCKED — una característica SQL disponible en PostgreSQL 9.5+ y MySQL 8+ que convierte una tabla relacional ordinaria en una cola de trabajo concurrente sin bloqueos.

La arquitectura se compone de tres elementos:

• Workers: consultan la tabla solid_queue_ready_executions y reservan jobs mediante SKIP LOCKED
• Dispatchers: mueven los jobs programados desde solid_queue_scheduled_executions hacia la tabla de listos cuando llega su momento de ejecución
• Schedulers: gestionan las tareas recurrentes definidas en la configuración

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

Esta configuración ejecuta dos procesos worker con 5 hilos cada uno, consultando la base de datos cada 100 ms. El dispatcher verifica los jobs programados cada segundo en lotes de 500.

Encolado transaccional en Rails 8

Uno de los argumentos más sólidos a favor de Solid Queue frente a los backends basados en Redis es el encolado transaccional. Cuando un job se encola dentro de una transacción de base de datos, solo se hace visible después del commit. Los backends de Redis no pueden ofrecer esta garantía — un job podría ejecutarse antes de que la transacción que lo creó finalice, referenciando registros que aún no existen.

# 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

Con enqueue_after_transaction_commit habilitado, el job se difiere hasta que la transacción que lo envuelve tenga éxito. Si la transacción hace rollback, el job nunca se encola. Esto elimina toda una categoría de condiciones de carrera que afectan a las colas respaldadas por Redis.

Controles de concurrencia y colas prioritarias

Solid Queue incluye controles de concurrencia nativos que Sidekiq solo ofrece en su versión Enterprise de pago. La opción concurrency_limit restringe cuántos jobs de un tipo determinado pueden ejecutarse simultáneamente.

# 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

Esta configuración asegura que como máximo 3 jobs de sincronización API se ejecuten simultáneamente por cuenta, previniendo violaciones de límites de tasa sin coordinación externa. Los jobs bloqueados se almacenan en solid_queue_blocked_executions y se liberan automáticamente cuando un espacio queda disponible.

La prioridad funciona en dos niveles: prioridad numérica por job (número menor = prioridad más alta) y orden de colas en la configuración del worker. Ambos se pueden combinar para un control detallado del orden de ejecución.

Jobs recurrentes sin cron

Solid Queue reemplaza la programación basada en cron con un scheduler integrado. Las tareas recurrentes se definen en un archivo de configuración YAML y son gestionadas por el proceso 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

El proceso scheduler lee este archivo y encola los jobs correspondientes en los intervalos definidos. A diferencia de cron, se ejecuta dentro del mismo supervisor de procesos y comparte la misma conexión a la base de datos.

Despliegue con integración Puma

Rails 8 con Kamal proporciona despliegue sin configuración para Solid Queue. El parámetro SOLID_QUEUE_IN_PUMA=1 indica a Puma que haga fork y supervise los procesos de Solid Queue junto al servidor web.

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

Este modelo de despliegue en un solo proceso simplifica la orquestación de contenedores. Una sola imagen Docker ejecuta tanto el servidor web como los procesadores de jobs, reduciendo la sobrecarga operacional para aplicaciones pequeñas y medianas.

Solid Cache: caché respaldado por base de datos que escala

Solid Cache es un ActiveSupport::Cache::Store respaldado por base de datos que aprovecha el rendimiento de los SSD modernos para reemplazar Redis y Memcached como almacén de caché por defecto. La premisa: los SSD son solo marginalmente más lentos que la RAM para operaciones de lectura, pero ofrecen órdenes de magnitud más almacenamiento a una fracción del costo.

Solid Cache utiliza una estrategia de expiración FIFO (First In, First Out) en lugar de LRU (Least Recently Used). Aunque FIFO es teóricamente menos eficiente, la capacidad de almacenamiento vastamente superior compensa — las entradas permanecen en caché mucho más tiempo, reduciendo los cache misses en general.

# 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

Arquitectura del caché y mecanismo de expiración

Solid Cache rastrea las escrituras mediante un contador interno. Cuando el contador alcanza el 50% del expiry_batch_size configurado, una tarea en segundo plano se activa para limpiar las entradas expiradas. Este enfoque amortizado evita las pausas de tipo stop-the-world que pueden ocurrir con la evicción LRU en instancias de Redis con memoria limitada.

La tabla solid_cache_entries almacena todos los datos en caché:

# 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

La lectura y escritura en esta tabla utilizan por defecto el mismo pool de conexiones que el resto de la aplicación. Para aplicaciones de alto tráfico, configurar una base de datos separada para los datos de caché evita que las operaciones de caché impacten el rendimiento de la base de datos principal.

Configuración de base de datos separada para el caché

Aislar Solid Cache en una base de datos dedicada es sencillo y recomendado para cargas de producción que generan tráfico de caché significativo.

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

Esta separación asegura que millones de operaciones de escritura de caché no inflen el WAL (Write-Ahead Log) de la base de datos principal ni compitan por espacios en el pool de conexiones con las consultas de la aplicación.

Sharding y cifrado

Solid Cache soporta el sharding de datos en caché a través de múltiples bases de datos para distribuir la carga. También soporta atributos cifrados — los datos en caché permanecen cifrados en reposo, un requisito de cumplimiento para aplicaciones que manejan información sensible.

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

Las entradas se distribuyen entre los shards usando hashing consistente sobre la clave de caché. Agregar o eliminar shards causa un aumento temporal en los cache misses mientras las entradas se redistribuyen, pero no se produce pérdida de datos.

Monitoreo con Mission Control Jobs

Mission Control Jobs proporciona un panel web para inspeccionar y gestionar los jobs de Solid Queue. Muestra los workers, las colas y los estados de los jobs (en progreso, finalizados, bloqueados, fallidos) a través de un engine Rails montado.

# 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 también expone una API de consola para operaciones masivas sobre jobs fallidos:

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

Este acceso programático es esencial para manejar fallos de jobs a gran escala sin necesidad de navegar manualmente por un panel de control.

Preguntas técnicas clave para entrevistas

Las entrevistas de Rails 8 se enfocan cada vez más en el stack Solid. A continuación, las preguntas que surgen con mayor frecuencia junto con la profundidad de respuesta esperada.

P: ¿Cómo logra Solid Queue procesar jobs de forma concurrente sin Redis? Solid Queue utiliza FOR UPDATE SKIP LOCKED, una cláusula SQL que permite a múltiples workers consultar la misma tabla sin bloquearse mutuamente. Cada worker bloquea un lote de filas, las procesa y elimina los registros de ejecución. Los demás workers omiten las filas ya bloqueadas y reservan jobs diferentes.

P: ¿Qué problema resuelve el encolado transaccional? Evita que los jobs se ejecuten antes de que la transacción de base de datos que los originó haya sido commitida. Sin esto, un job podría referenciar un registro que fue revertido mediante rollback, causando errores ActiveRecord::RecordNotFound.

P: ¿Por qué Solid Cache usa FIFO en lugar de LRU? FIFO es más simple de implementar en una base de datos y evita la amplificación de escritura al no necesitar actualizar marcas de tiempo de acceso en cada lectura. La compensación viene de la capacidad SSD — las entradas permanecen más tiempo, por lo que la tasa de aciertos se mantiene alta a pesar de la estrategia de evicción menos óptima.

P: ¿Cuándo debería una aplicación seguir usando Redis en lugar del stack Solid? Redis sigue siendo superior para aplicaciones que procesan más de 10,000 jobs por minuto, cargas que requieren lecturas de caché por debajo del milisegundo, o aplicaciones que ya utilizan Redis para otros propósitos (Pub/Sub, rate limiting, almacenamiento de sesiones). El stack Solid apunta a la simplicidad, no al rendimiento máximo.

Estas preguntas y muchas más se pueden practicar en los módulos ActiveJob y trabajos en segundo plano y Estrategias de caché de SharpSkill.

Conclusión

• Solid Queue reemplaza las colas de jobs basadas en Redis con una solución respaldada por base de datos usando FOR UPDATE SKIP LOCKED para procesamiento concurrente
• El encolado transaccional elimina las condiciones de carrera entre escrituras en base de datos y ejecución de jobs — una garantía que Redis no puede proporcionar
• Los controles de concurrencia integrados, jobs recurrentes e integración con Puma se incluyen en Solid Queue sin costo adicional
• Solid Cache utiliza caché FIFO respaldado por SSD con sharding y cifrado opcionales, eliminando Memcached y Redis de la pila de infraestructura
• La configuración de una base de datos separada para Solid Cache evita que las operaciones de caché impacten el rendimiento de la base de datos principal
• Mission Control Jobs proporciona monitoreo en producción y gestión masiva de jobs a través de un panel web y una API de consola
• Para la mayoría de las aplicaciones Rails 8 en 2026, el stack Solid es la opción por defecto recomendada — Redis sigue siendo la elección solo para casos de alto rendimiento que superan los 10,000 jobs por minuto