Safely Decomposing a Highly Available Rails App

on YouTube ↗20m

" summary

A 100,000-line legacy Rails monolith gets a new Rails 4.1 API app and is validated by an in-process quackery proxy that dual-calls old and new code so responses can be compared; heavy use of double-writing via rolled-back DB transactions lets non-idempotent endpoints be checked against real state while sharing one PostgreSQL database. Performance work uses PG Bouncer, OJ, rails_api, nginx + unicorn and short caches to hit single-digit millisecond requests. The DB split proceeds with a read‑only mode, leaving only minutes of degraded noncritical UI and jobs.

AI-written summary · about

" chapters (12)

1. 0:00Start
2. 0:36Decomposing a Highly Available Rails App
3. 1:18Context
4. 3:22High-Level Strategy
5. 6:52Connection Overhead
6. 8:13Code Correctness
7. 8:46Shared Context
8. 10:22Proxy Layer
9. 15:19Split the Database
10. 16:04Db Dump and Reload
11. 17:35Optional Auditing and Analytics
12. 18:11Read-Only Mode

" related talks

• 32mRefactoring Legacy Apps with APIs and MessagesCorey Ehmke · LoneStarRuby Conf 2013
• 56mScaling Rails API to Write-Heavy TrafficTakumasa Ochi · RailsConf 2021
• 36mWorking Compassionately with Legacy CodeAmar Shah · RubyConf 2015
• 27mScaling a Rails Monolith w/Event Driven MicroservicesMarko Anastasov · WindyCityRails 2016
• 42mHow Rails fosters a diverse and competitive tech ecosystem in the era of big techJordan Trevino · RailsConf 2023
• 26mMonolith-ifying perfectly good microservicesBrian Scanlan · LDX3 London 2025
• 27mFrom multiple apps to MonolithKaja Santro · EuRuKo 2019
• 32mHow I architected my big Rails app for success!Ben Smith · Rocky Mountain Ruby 2013