A RAILS PERFORMANCE GUIDEBOOK
summary
Claims that real Rails scaling relies on monitoring, focused database work and pragmatic architecture rather than magic. Zendesk runs 2 billion requests per day, stores over 20 million tickets and one table with trillions of rows, so techniques are concrete: sampling and latency error budgets, indexes plus EXPLAIN ANALYZE, sharding by customer, avoiding SELECT and focusing on p99s, right‑through caching that cut a ticket side‑load from 40ms to 5ms (50,000 calls/day → eight+ days saved/year), archiving old rows to Dynamo/S3, and sensible rate limits*.
AI-written summary · about
chapters (18)
- 0:00Rails performance challenges
- 3:09Rails scalability myths
- 6:17Easy Rails scaling illusions
- 7:20Zendesk Rails performance
- 9:06Monitoring for performance
- 11:13Database query essentials
- 12:16Sharding in Rails
- 12:58Avoid over-fetching in Rails
- 14:03Danger of complex Rails queries
- 14:25Advanced Rails caching
- 16:36The dangers of misusing Rails gems
- 19:24Storage for big Rails data
- 22:57Product limits in Rails
- 24:42Bloat in Rails endpoints
- 25:25Slow Rails workflows
- 27:14Eventual consistency in Rails
- 27:57Rails performance mindset
- 30:45Conclusion
related talks
31mA Rails performance guidebook: from 0 to 1B requests/day
29mA Rails Performance Guidebook: from 0 to 1B requests/day
14mDatabase Performance at Scale for RoR Applications
29mScaling Rails to 2M MySQL requests per second
26mRails Performance Monitoring 101: A Primer for Developers
48mOn the Edge of Rails Performance
24mPlan to scale or plan to fail: an evidence-based approach for improving systems performance
01h 03mThe Trail to Scale Without Fail: Rails?