The Modern Rails Stack (Rails 8+)

The big shift

Rails 8 made the "database does everything" stance the default. Background jobs, cache, cable, and HTTP cache used to require Redis or Memcached in production. The Solid family of libraries lets Postgres handle all of them. The motivation: one fewer infrastructure dependency, one less thing to provision, one less thing to monitor.

The trade-off: Postgres is slower than Redis for cache reads and queue polls. For most apps under a few thousand requests per minute, the difference doesn't matter. For very high traffic, you still reach for Redis.

Solid Queue (replaces Sidekiq for many apps)

A background job processor that uses Postgres for its queue. ActiveJob-compatible, so you don't change job code; you change the adapter.

• When to choose: moderate throughput (low thousands of jobs per minute), team already maintains Postgres, prefers fewer moving parts.
• When to stay on Sidekiq: very high throughput, complex workflows (Sidekiq Pro/Enterprise features like batches), or you already have Redis for other reasons.
• Interview tell: if you can name "polling vs push" as the architectural difference (Solid Queue polls Postgres; Sidekiq listens on Redis), you've understood the question.

Solid Cache (replaces Memcached/Redis for Rails.cache)

Rails.cache backed by a Postgres table. Same API; Rails.cache.fetch works exactly the same way. The difference is where the data lives. For cache stampede protection, the same patterns (race_condition_ttl, TTL jitter, soft-expiration) apply identically.

Trade-off: Postgres can cache megabytes of HTML responses and tolerate a billion-key working set with disk-backed durability; Memcached can't. Memcached is faster for very hot small keys; Solid Cache wins on cold-key recovery (no warmup after a restart).

Solid Cable (replaces Redis for Action Cable)

The pub/sub layer that backs Action Cable. Pushes broadcasts through Postgres LISTEN/NOTIFY instead of Redis Pub/Sub. Same Action Cable API on the application side.

Trade-off: works well for typical chat / live-update workloads. Postgres LISTEN/NOTIFY has lower throughput than Redis Pub/Sub at the high end; if your app is broadcasting tens of thousands of messages per second across a fleet, Redis is still the right choice.

Hotwire (Turbo + Stimulus)

Rails 7 made Hotwire the default JS layer. Rails 8 doubled down. Two pieces:

• Turbo Drive. Intercepts link clicks and form submissions, replaces the body of the response, no full page reload. Free.
• Turbo Frames. A region of the page that can be replaced independently. Server-rendered HTML, no JSON.
• Turbo Streams. The server pushes HTML fragments down a WebSocket (or after a form submit) that target specific elements: append, prepend, replace, update, remove. The "live update" pattern.
• Stimulus. Small JS controllers for sprinkles of behavior. Not a SPA framework. Adds event handlers to existing HTML.

Interview tell: if you can explain "Turbo Frame vs Turbo Stream" — frame is a region the client can reload, stream is the server pushing changes — you've grasped the model.

Kamal (replaces Heroku-style deploys)

The DHH-flavored deploy tool. SSH into your servers, pull a Docker image, swap containers with zero downtime, run on commodity hardware (Hetzner, your own data center). The "post-Heroku" story: own your servers, deploy with one command.

Trade-off: less hand-holding than Heroku or Render. You manage SSH keys, certs, and the underlying VMs. For teams that want it, the cost savings are dramatic. For teams that don't have the operational appetite, hosted PaaS is still right.

What this signals in an interview

Saying "I use Solid Queue" or "I use Sidekiq" is a syntax answer. Saying "we picked Solid Queue because our throughput is under 500 jobs per minute and we wanted one fewer infrastructure dependency; if we cross 5K/min we'll re-evaluate" is a senior answer. The interviewer is listening for the trade-off, not the choice.