How to get away with refactoring
summary
Slack faces escalating scale from 2M to 6M DAUs and fixes a chronic morning-outage pattern by changing the data model for channels and membership. Key outcomes and methods: consolidated channels and memberships into one table, replaced duplicated queries spread over ~400 call sites in ~100 files, use feature flags and dashboards to roll and monitor changes, months-long rewrite with documented plan that uncovered 9M Slackbot conversations and a DM with 22M messages, enabling safer deletes, easier recoveries, and measurable performance stability.
AI-written summary · about
chapters (20)
- 0:00Intro
- 1:09What is refactoring
- 2:33Why you shouldnt refactor
- 5:44What could go wrong
- 6:35Refactoring
- 7:10Storytime
- 8:50Slack
- 9:38Schema
- 10:19Problems
- 14:26Solutions
- 16:51Plan
- 18:44Mistakes
- 19:32Other tips
- 20:35Future flags
- 21:23Dashboards
- 22:02Bugs
- 22:34Documentation
- 24:02Channel deletion
- 25:27Celebrate
- 26:22Cleanup
related talks
01h 02mTools for simplified large scale systems
18mTackling tech debt
37mHow Small Changes Can Make Huge Waves
30mService Ownership @Slack
42mAvoiding Microservice Megadisaster
27mLessons from a Year with Backstage: What Worked, What Didn’t...
31mThe Skype Journey to 1ES and Cloud
31mOn the Importance of Visibility