Solid Queue & Solid Cache: Zero-Downtime Production Architecture Guide

Direct Answer: Solid Queue and Solid Cache

Solid Queue and Solid Cache revolutionize Rails 8 backend operations by leveraging standard databases for background jobs and caching. This architecture eliminates external dependencies like Redis and Sidekiq, drastically reducing infrastructure costs, simplifying deployments, and scaling effortlessly for high-throughput enterprise Ruby on Rails applications.

Introduction to Modern Rails Infrastructure

For over a decade, the standard Ruby on Rails stack relied heavily on Redis for caching and Action Cable, paired with Sidekiq or Resque backed by Redis for asynchronous job processing. While performant, this multi-service architecture introduces persistent operational overhead: managing dedicated Redis clusters, monitoring memory fragmentation, handling eviction policies, and syncing multiple stateful backing services across containerized environments like Docker and Kubernetes.

With the release of Rails 8, Basecamp introduced Solid Queue and Solid Cache (alongside Solid Cable), shifting the paradigm back to the relational database. By utilizing database-backed queues and caching tables, modern Rails architectures achieve transactional consistency out of the box. Jobs and cache entries participate in the same database transactions as your core business logic, eliminating race conditions where a record is created but the background job fails to find it because of network lag.

At TechVinta, our Principal Solutions Architects help high-growth engineering teams transition legacy, multi-node infrastructure into lean, database-driven setups using Kamal 2 and Rails 8. If your organization is evaluating a migration or requires expert guidance, our engineering team offers direct consultations with a 4-to-6-hour US timezone overlap.

Core Architectural Architecture: Solid Queue & Solid Cache

Understanding how these gems interact with your primary database is vital for high-throughput production environments. Unlike traditional Redis setups that keep data in volatile RAM (requiring persistence configurations like RDB or AOF), Solid Queue and Solid Cache persist data directly into dedicated PostgreSQL, MySQL, or SQLite tables.

Solid Queue Mechanics

Solid Queue replaces Sidekiq by utilizing relational tables: solid_queue_jobs, solid_queue_processes, solid_queue_ready_jobs, and solid_queue_claimed_jobs. It uses database-level row-locking (e.g., SELECT ... FOR UPDATE SKIP LOCKED) to coordinate multiple worker processes safely without deadlocks.

Solid Cache Mechanics

Solid Cache leverages a single, optimized table (solid_cache_entries) with binary storage (BLOB) for keys and values, coupled with a strict database index strategy. Because cache eviction is handled via automated batch deletion or background sweeps, it maintains lightning-fast performance even when holding hundreds of millions of keys.

Production Implementation & Configuration

Implementing Solid Queue and Solid Cache in a Rails 8 application requires configuring dedicated database connections to avoid saturating your primary database connection pool with heavy background worker queries.

1. Gemfile and Database Configuration

Ensure your Gemfile includes the core gems (included by default in Rails 8 new applications):

gem "solid_queue"
gem "solid_cache"

Next, configure your config/database.yml to establish multi-database isolation. This isolates heavy queue polling and cache writing from your primary transactional workload:

production:
  primary: &primary_production
    <<: *default
    database: app_production
    username: app
    password: <%= ENV['DATABASE_PASSWORD'] %>
    pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

  cache:
    <<: *primary_production
    database: app_production_cache
    migrations_paths: db/cache_migrate
    pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

  queue:
    <<: *primary_production
    database: app_production_queue
    migrations_paths: db/queue_migrate
    pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 10 } %>

2. Framework Configuration

Configure your application environments in config/environments/production.rb to instruct Rails to route cache and queue operations to their respective configurations:

Rails.application.configure do
  # Use Solid Cache for the Rails cache store
  config.cache_store = :solid_cache_store

  # Use Solid Queue for Active Job backend
  config.active_job.queue_adapter = :solid_queue
  
  # Solid Queue supervisor configuration
  config.solid_queue.connects_to = { database: { writing: :queue } }
end

3. Solid Queue Dispatcher and Worker Configuration

Solid Queue runs via a supervisor process configured in config/solid_queue.yml. This file defines how dispatchers, workers, and recurring tasks are managed:

production:
  dispatchers:
    - polling_interval: 1
      batch_size: 500
  workers:
    - queues: "*"
      threads: 5
      processes: 2
      polling_interval: 0.5
    - queues: [critical, mailers]
      threads: 3
      processes: 1
      polling_interval: 0.2

Commercial Pricing, Timeline, and Architecture Comparison

When planning infrastructure modernizations, engineering leaders must balance migration costs, ongoing maintenance overhead, and hosting bills. Below is a detailed commercial comparison for 2026 infrastructure strategies.

Engineering Services & Partnership with TechVinta

Migrating production workloads from legacy background processors to Solid Queue and Solid Cache requires deep expertise in database indexing, connection pooling tuning, and zero-downtime deployment pipelines using Kamal 2 or Docker. TechVinta provides elite, senior-level engineering teams operating with a seamless 4-to-6-hour US timezone overlap. Whether you need a comprehensive architecture audit, hands-on migration execution, or custom marketplace development, our engineers ensure robust, high-performance production outcomes.

Frequently Asked Questions

Can Solid Queue handle high-frequency job execution like Sidekiq?

Yes. Solid Queue uses database row locking (FOR UPDATE SKIP LOCKED) which scales efficiently across multiple worker processes. While extremely high-throughput systems processing tens of thousands of jobs per second may require careful PostgreSQL tuning and connection pooling, typical production workloads running thousands of jobs per minute execute with minimal database load and absolute transactional consistency.

How do I handle cache eviction and table bloat with Solid Cache?

Solid Cache automatically manages table bloat and key expiration. It utilizes a generational or LRU-based batch pruning strategy configured via standard Rails cache options. Because entries are stored in a dedicated database table, standard database maintenance routines (like automated vacuuming in PostgreSQL) keep index and table bloat well under control without requiring manual intervention.

Is it possible to migrate an existing Rails application from Sidekiq to Solid Queue with zero downtime?

Yes. Because Active Job abstracts the underlying queue adapter, you can run a phased rollout. You can deploy changes where new jobs are enqueued via Solid Queue while draining existing legacy queues, or use dual-adapters temporarily during the transition window. TechVinta routinely executes these zero-downtime cutovers for enterprise Rails clients.