[00:03] Wrong. Slack's MySQL database handles over 1.5 billion messages every single day. They started with MySQL sharded by workspace. Each company's data lived on its own database cluster, and the application code handled the routing.
[00:18] When most teams were small, this worked great. The load spread out naturally. But then big enterprise showed up. Now you've got a single company with tens of thousands of users, and all their messages, channels, and DMs are
[00:31] hammering one cluster. So it became a hotspot. And because the routing logic is baked into the app, there's no way to break it up further. So they migrated to Vitess, an open-source system originally built at
[00:43] YouTube that makes MySQL horizontally scalable. Basically, it lets you shard your database without your apps having to know about it. So instead of only splitting data by workspace, Vitess let them split by users, channels, or
[00:56] workspaces independently. The app just talks to Vitess like it's one giant database, and Vitess figures out where to send each query behind the scenes. Now it's been over 3 years since the migration, and 99% of their MySQL
[01:10] traffic runs through this system. That's 2.3 million queries per second at peak, a median latency of 2 milliseconds, and over 40 million daily active users, all So next time someone tells you your relational database doesn't scale, send
[01:25] relational database doesn't scale, send them this.