How Solid Queue works under the hood

Whether or not you're active in the Rails ecosystem, you might already have heard some of the buzz around Solid Queue, a new database-backed backend for ActiveJob. Solid Queue is a simple and performant option for background jobs that lets you queue large amounts of data without maintaining extra dependencies like Redis.

We've already talked about how to deploy, run, and monitor Solid Queue, but we haven't yet explored how Solid Queue works. In this article, we'll explore the implementation of Solid Queue. We'll follow a Solid Queue job from start to finish by digging into what happens when you enqueue a job with ActiveJob, examining the many database tables, and exploring how jobs get executed.

Solid Queue leans on several different tables to manage jobs throughout their lifecycle. It can be a lot to keep track of! Knowing what each table represents and how Solid Queue uses them to keep track of state can be helpful for debugging. To start, here's a quick list of the tables:

Rails applications don't get these tables by default; Solid Queue creates a migration file when you run the install command:

Leave a Comment