Back of the envelope estimation

A design only makes sense for a given load. A service with 100 users a day and one with 100 million need different architectures, and the only way to know which you have is to calculate. Estimation is not about being exact. It is about being right to within a factor of ten, because that is the difference between "one database is fine" and "we must split the data".

We keep the same example: a link shortener with 500 million new links per month and 100 reads for every write.

Computers count in powers of two, but you can think in powers of ten and be close enough.

• 1 thousand is about 2^10, so a kilobyte (KB).
• 1 million is about 2^20, so a megabyte (MB).
• 1 billion is about 2^30, so a gigabyte (GB).
• 1 trillion is about 2^40, so a terabyte (TB).

Speed matters just as much. Rough latencies, to the nearest order of magnitude:

• Reading from memory: about 100 nanoseconds.
• Reading from an SSD: about 100 microseconds, roughly 1,000 times slower than memory.
• A round trip inside one data center: about 0.5 milliseconds.
• A disk seek: about 10 milliseconds.
• A round trip across continents: about 150 milliseconds.

The lesson in that list: memory is cheap to read, the network is not, and crossing an ocean is very expensive. This is why caches and nearby servers exist.

Convert everything to seconds. A day has 86,400 seconds, which we round to about 100,000 when we need speed. A month has about 2.6 million seconds (30 x 86,400).

• Writes: 500M / 2.6M is about 200 new links per second.
• Reads: 100 times that, so about 20,000 redirects per second.
• Peak: traffic is never flat. A safe rule is to plan for 2 times the average, so about 40,000 reads per second at peak.

Storage is the number of records, times the size of each record, times how long you keep them.

• 500M links per month x 12 months x 5 years is 30 billion links.
• At about 500 bytes per record (the key, the long address, dates, owner), that is 30B x 500 B = 15 TB.
• Keep three copies for safety and you need about 45 TB.

A related question is how long each key must be. A key made of 62 characters (a to z, A to Z, 0 to 9) gives 62^6, about 56 billion, with six characters and 62^7, about 3.5 trillion, with seven. Thirty billion links fit comfortably in six or seven characters.

Bandwidth is requests per second times the size of each request.

• Incoming: 200 writes per second x 500 B is about 100 KB per second.
• Outgoing: 20,000 reads per second x 500 B is about 10 MB per second.

Both are tiny. The network is not our problem. The next question is memory for a cache. Real traffic follows the 80/20 rule: about 20 percent of links produce about 80 percent of the reads. So we cache that hot 20 percent.

• Reads per day: 20,000 x 86,400 is about 1.7 billion.
• Hot 20 percent: about 350 million records.
• Memory needed: 350M x 500 B is about 170 GB.

That is a handful of machines, not a data center.

Each number should lead to a choice. If it does not, you calculated something you did not need.

• 200 writes per second: one database can take this, so writes are not the hard part.
• 20K to 40K reads per second: this is why we add a cache and several servers.
• 15 TB over five years: more than one comfortable machine, so plan to split or add disks.
• 10 MB per second: no special network planning.

Habits that keep estimates honest: say your assumptions aloud, round aggressively, keep units on every number, remember bits are not bytes, include replicas in storage, and ask whether you are looking at average or peak. If an answer looks absurd, it probably is, so check it against something you know.