Step 1: Use cases, constraints and estimates

Four steps

The System Design Primer describes a system design interview as an open-ended conversation that you are expected to lead, and offers four steps to guide it:

1. Outline use cases, constraints, and assumptions.
2. Create a high level design.
3. Design core components.
4. Scale the design.

Each of the primer's worked solutions (the capstones that follow this chapter) is written in exactly these four steps. Back-of-the-envelope estimates are not a separate step: in every solution they sit inside step 1, under "Calculate usage", and the primer adds that you may be asked to make such estimates by hand. This lesson covers step 1; the next three cover one step each.

Step 1: use cases

Step 1 is about the problem, not the solution. Gather requirements and scope the problem: ask questions to clarify the use cases and constraints, and discuss your assumptions. The primer's questions are:

• Who is going to use it, and how?
• How many users are there?
• What does the system do? What are its inputs and outputs?
• How much data do we expect to handle?
• How many requests per second do we expect?
• What is the expected read to write ratio?

Write the answers down as use cases, and say just as clearly what is out of scope. In the primer's Pastebin solution, the use cases are: a user enters a block of text and gets a randomly generated link, with an optional expiry; a user enters a paste's link and views its contents; users are anonymous; the service tracks monthly page-visit statistics, deletes expired pastes and has high availability. Registering an account, logging in, editing a paste, setting visibility and choosing your own short link are all declared out of scope. Scoping is what makes the rest of the hour possible.

State assumptions

Constraints you are not told, you assume, and say so. The Pastebin solution assumes:

• traffic is not evenly distributed;
• following a short link should be fast;
• pastes are text only, and page-view analytics need not be real time;
• 10 million users, 10 million paste writes and 100 million paste reads per month, so a 10:1 read to write ratio.

The first two shape the design as much as any number: uneven traffic is why the design will need headroom and a cache, and "fast to follow" is why reads get their own path.

Calculate usage

The primer suggests checking with the interviewer whether they want these calculations. When they do, three conversions carry most of the work. A month has about 2.5 million seconds (30 days is $2{,}592{,}000$; the primer rounds), so:

• 1 request per second is 2.5 million requests a month;
• 40 requests per second is 100 million a month;
• 400 requests per second is 1 billion a month.

For Pastebin: 10 million writes a month is 4 writes per second on average, and 100 million reads is 40 reads per second.

Storage follows from the size of one record. A paste is 1 KB of content plus a 7-byte short link, a 4-byte expiry, a 5-byte creation time and a 255-byte path: about 1.27 KB. Then:

which is about 450 GB over three years, and 360 million short links.

These are averages. The assumption that traffic is uneven means the peak is higher; the primer's solutions say "higher at peak" and do not put a number on it. If the peak matters to the design, ask, or state the multiple you are assuming.