A Rails performance guidebook: from 0 to 1B requests/day
summary
Rails service handles over 2 billion requests/day at Zendesk, with relational stores ~400 TB and a single sharded table hitting 60 TB. Practical fixes: add APMs and sampling, set latency error budgets and watch p99 latency, fix N+1s, add proper indexes and use pluck/select to avoid fetching gigabytes. Build a write-through cache for precomputed API views, archive closed tickets after 120 days to cold storage (90%+ of data), apply per-customer sharding, rate limits, and async writes — these measures work and cut compute and outages.
AI-written summary · about
chapters (16)
- 0:00Rails scaling challenges
- 2:07Why Rails feels easy to scale
- 5:14Scaling Rails reality
- 7:40Performance engineering mindset
- 8:25Monitoring performance role
- 10:51Database optimizations
- 13:42P99 latency importance
- 14:23Caching strategies at scale
- 16:33Doraemon paradox
- 19:03Cold storage scaling
- 21:35Archiving data load
- 23:01Products and performance limits
- 24:50Bloated API dangers
- 25:50Slow workflows breakdown
- 27:58Large customers handling
- 29:00Performance trade-offs
related talks
31mA RAILS PERFORMANCE GUIDEBOOK
29mA Rails Performance Guidebook: from 0 to 1B requests/day
14mDatabase Performance at Scale for RoR Applications
26mRails Performance Monitoring 101: A Primer for Developers
24mFrom Expensive Queries to Smart Caching: A DBA’s Guide for Rails
56mScaling Rails API to Write-Heavy Traffic
37mScaling Rails for Black Friday and Cyber Monday
28mServices and Rails: The Shit They Don't Tell You