The Solid Stack strategy
This course weighs the Solid stack as an architecture decision for Rails applications. It sets the operational gains of running jobs, cache and pub/sub in Postgres against the cost of concentrating load on one database. Lessons cover durability, backups and monitoring, four workloads where Redis or a dedicated queue fits better, the connection budget and blast radius, and daily operations such as restores and migrations. It closes with the shape of the bill, including engineering time, and a reversible migration path off Redis, plus Kamal and Thruster.
What you'll learn
- ✓Weighing the operational gains of running jobs, cache and pub/sub in Postgres
- ✓Recognizing workloads where Redis or a dedicated queue is the better choice
- ✓Calculating the Postgres connection budget across web, job and polling processes
- ✓Adapting backup, restore, migrations and alerting to a single database
- ✓Comparing the shape of infrastructure and engineering costs
- ✓Planning a reversible migration off Redis
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…
Read the full lesson free →Curriculum
7 lessonsThe trade you are actually making
Compares a four-box Rails deployment with the two-box Solid stack and frames the choice as a workload decision.
What consolidation actually buys
Explains the operational gains of consolidation: one durability model, backup story, monitoring surface and thing to learn.
When consolidation is the wrong call
Describes four measurable workloads where keeping Redis or running a dedicated queue is the correct decision.
Blast radius and the connection budget
Counts Postgres connections across web, jobs and pollers, and examines the correlated failure that consolidation creates.
Operating one system instead of four
Covers how backups, schema migrations, monitoring and capacity planning change when one Postgres replaces four systems.
The shape of the bill
Compares the shape of both bills, including engineering hours and one-time migration cost, instead of vendor prices.
Migrating off Redis, and what comes next
Plans a reversible move off Redis, cache first and jobs last, and places Kamal and Thruster in the argument.