Work chat database system design

Questions to ask the interviewer

The design in short

A chat app sold to companies. About 1,000 companies pay for one work chat app. Each company has its own channels, people and messages, and no company ever reads another's. This interview asks how you split the data between machines, and how a request finds the right place for its company.

The design in short. App servers sit behind a load balancer and take every request. One database holds the data, split into shards. Each company lives on one shard, so its queries never have to ask the others.

Count it. The brief gives 3,000 requests a second, and 87% of them are reads. The data is 4 TB today. One database machine holds 2 TB, whatever its size, so the data cannot fit on one machine. Answers must come back in under 300 ms on average. Count the disk and the queries before you pick a number of shards.

Items to draw on the whiteboard:

• the load balancer and the app servers behind it
• the shards, and what decides which shard holds a company
• how a request finds its company's shard
• what happens when one company grows faster than the rest

Not all companies are alike. Most companies are small, but one is a giant: it holds 1.5 TB of the 4 TB and makes about a third of all the queries. Ask where the giant lives, which other companies share its shard, and who decides that. A formula decides alone; a small table can be changed by a person.

Stay inside the brief. Search, files, calls and sign-in would each fill an interview of their own. Leave them for later and talk about messages and the data around them.

Build it in GonnaCrash and see which shard fills up first.

The post behind this problem

Slack's engineering team tells the story this problem follows in Scaling Datastores at Slack with Vitess. Read it after you play: it gives away what each round asks for. Real systems: MySQL, Vitess.