The trade you are actually making

Draw the boxes for a conventional Rails deployment and you get four of them. A web tier runs Puma. A worker tier runs Sidekiq. A Redis instance is what the workers poll, and a Postgres instance holds the data. That's four things that can be down, four things with a version and four things with a backup story. It's also four things a new hire has to learn about in their first week.

Now draw this application. For the part this course cares about, there's a Postgres container and an app container. Inside the app container, Puma runs the web server and the job supervisor in the same process tree. Jobs, cache and pub/sub all live in Postgres. config/deploy.yml says so in one line:

# No separate job container: run Solid Queue inside Puma.
SOLID_QUEUE_IN_PUMA: "true"

Four boxes became two. That's the Solid stack. The mid-level course "Solid Queue: database-backed", the junior course "Solid Cache: database caching" and the mid-level course "Solid Cable: scale" showed you how each piece works. This course asks whether you should do it. That's a different question, with a different answer depending on who's asking.

This is a decision, not a feature

Nobody adopts the Solid stack because a connects_to call is elegant. They adopt it because they're accountable for something. It might be a bill that arrives monthly, a pager that goes off at night or a hiring plan that has to produce someone who can operate the thing. The Solid stack moves cost around between those three. The whole skill is seeing which direction it moves for your team.

What you gain is subtraction. You get one durability model instead of two, and one backup and restore procedure. You get one set of connection strings, one system to monitor, one capacity curve to plan against and one thing to learn. When Redis is gone, so is every question that starts with "wait, is that in Redis or in Postgres?"

What you pay is concentration. Job polling, cache reads and writes, and pub/sub message inserts all used to run on hardware that wasn't your database. Now they run on hardware that is. The load didn't vanish. It moved onto the one component whose failure was already the worst failure you had.

Say the ceiling out loud

A default nobody can argue against is a fashion, not an engineering choice. Solid Queue polls a table with FOR UPDATE SKIP LOCKED. That's a good mechanism, and it's still a table, on a disk, with an index and a write-ahead log. Redis answers from memory. At some throughput, the difference stops being academic and starts showing up on your latency graph. Part of this course is finding where that point is for a given workload, and being able to say it without flinching.

The engineers who get this wrong in both directions are the same engineers. One group adopts the Solid stack for a system that needs a dedicated queue, and spends a quarter finding out. The other runs a Redis, a worker tier and an on-call rotation for an application that dispatches four hundred jobs a day. Both failed the same test: they picked an architecture without naming the workload it was for.

What's verified here, and what isn't

The examples in this course are read out of this repository, because this application runs the whole stack. The Gemfile declares solid_cache, solid_queue and solid_cable. config/cache.yml, config/queue.yml and config/cable.yml all exist and are wired up. In production, two of the three roles point at the primary database and one doesn't, for a reason written into the config file as a comment. You'll read all of it.

What this course won't do is pretend a small teaching platform proves anything about a system doing fifty thousand jobs a minute. A real, small, running configuration is worth more than a hypothetical large one, as long as nobody claims they're the same thing.

Where this course goes

Lesson 2 makes the case for consolidation as strongly as it deserves. It covers what disappears from your operational surface, and why "fewer moving parts" is a real engineering argument rather than a slogan.

Lesson 3 makes the case against, just as strongly. It covers four workloads where a separate Redis or a dedicated queue is the right call, and how to recognize them before you commit.

Lesson 4 covers blast radius and the connection budget. It asks what happens when queue, cache and pub/sub all land on the same Postgres, and how to count the connections before production counts them for you. It carries this course's coding challenge.

Lesson 5 covers operations: backup, restore, migrations, monitoring and capacity planning. All of them change shape when four systems become one.

Lesson 6 covers money, honestly. It's about the shape of the bill instead of vendor prices, including the part of it that's salaried engineers rather than infrastructure.

Lesson 7 is the migration path for a team already on Redis, plus where Kamal and Thruster sit in the same argument.

Start with the case in favor. It's stronger than the marketing makes it sound, for a specific reason. What it removes isn't a server. It's a category of question nobody on your team ever has to ask again.