Solid Queue - Default Active Job Adaptor in Rails 8
summary
Solid Queue becomes the default Active Job adapter in Rails 8, replacing Redis-based backends by running jobs in the application database and claiming fewer external dependencies. Installation uses a gem, runs one migration set that creates 10 database tables, and a configurable server with dispatchers, workers, scheduler and supervisors. Features include no Redis dependency, lifecycle hooks, retries, a Puma plugin, and job-level concurrency via limits_concurrency(key, limit, duration, group); it works for most apps but can hit limits under very high I/O workloads.
AI-written summary · about
chapters (13)
- 0:00Introduction to Solid Queue
- 1:21Installing Solid Queue
- 2:49Solid Queue Database Tables
- 4:40Solid Queue Actors Explained
- 5:45Job Processing Workflow
- 7:37Handling Job Failures
- 8:43Configuration Overview
- 10:09Dispatcher Settings
- 10:49Worker Configuration
- 11:31Concurrency Control
- 13:50Concurrency Example
- 14:38Concurrency Use Cases
- 15:27Q&A and Wrap-Up
related talks
27mFrom Resque to SolidQueue - Rethinking our background jobs for...
17mActiveJob: A Service Oriented Architecture
55mThe Past, Present and Future of Background Job...
35mSidekiq at Gusto: The Parts Where People’s Jaw Drops
28mFair by design: orchestrating background jobs in Ruby
41mInside ActiveJob
39mAsynchronous Workers to the Resque
34mBeyond CRUD: the PostgreSQL techniques your Rails app is missing.