In Module 9 we met sharding as the step you put off for as long as you can. In Module 13 we copied data onto several machines so it would survive failures and serve more reads. Copies have one big limit, though: every copy holds all the data and applies every write. If the data or the writes outgrow one machine, more copies don't help at all.
This module is about the other way to use many machines: give each one a different slice of the data. That's partitioning. It sounds simple, and the basic idea is. The hard parts are choosing how to slice, keeping the slices fair, and moving slices around while the system is busy.
Where Tiffin is now
Tiffin is no longer one city. It runs in 40 cities with 60,000 restaurants and 4 million orders a day. At dinner, around 150,000 riders are on shift, and each rider's phone sends a location update every 4 seconds.
Let's look at two kinds of data and ask whether one machine can hold them.
Orders. Say an order, with its items, status history and indexes, takes about 3 KB on disk.
- 4 million orders x 3 KB = 12 GB a day.
- 12 GB x 365 = about 4.4 TB a year, before indexes grow or anything else is stored.
A big database server can hold that for a while, especially with archiving (Module 9). Storage alone isn't what forces the issue.
Rider locations. This is the write problem.
- 150,000 riders / 4 seconds = 37,500 writes a second at dinner.