Scaling Rails to 2M MySQL requests per second

on YouTube ↗29m

" summary

Intercom hits 2 million MySQL requests/sec and solves it with concrete tactics: deploys identity_cache to cut DB reads (cache serves ~10M reads, but introduces stale-read consistency tradeoffs), moves heavy reads to replicas using a proxy adapter (complex, Rails-API fragile), horizontally shards a 25-billion-row conversations table into per-customer shards to make migrations resumable, and migrates off Aurora to PlanetScale/Vitess to split into 128 smaller nodes and enable near zero‑downtime resharding and host replacement.

AI-written summary · about

" chapters (11)

1. 0:00Scaling Rails at Intercom
2. 1:52Why Intercom needs 2 million database requests per second
3. 2:55Vertical scaling trade-offs
4. 6:22Vertical sharding in 2014
5. 8:44Feature-specific databases
6. 10:102015 outages and caching
7. 15:23Read replicas in 2016
8. 20:41Horizontal sharding in 2019
9. 24:57Aurora upgrade in 2024
10. 26:00Migrating to PlanetScale
11. 28:07Summary and future plans

" related talks

• 56mScaling Rails API to Write-Heavy TrafficTakumasa Ochi · RailsConf 2021
• 14mDatabase Performance at Scale for RoR ApplicationsRocio Delgado · GORUCO 2016
• 31mA RAILS PERFORMANCE GUIDEBOOKCristian Planas · Euruko 2023
• 46mScaling With FriendsGeoffrey Dagley · Big Ruby 2013
• 24mFrom Expensive Queries to Smart Caching: A DBA’s Guide for RailsJavier Zon · XO Ruby Atlanta 2025
• 37mDenormalizing RailsDaniel Lucraft · Ruby Manor 2: Manor Harder
• 33mAsynchronous RailsSamuel Williams · RubyConf AU 2023
• 27mGrowing data in a Ruby worldTamar Rucham · Rubyfuza 2018