Steps to approach a system design interview

1. Clarify requirements.
   1. Highly important: understand who is going to use the system and how. Call it out explicitly and don’t make assumptions.
      1. Internal or public facing.
      2. How can you extend the system in future, but that’s far less important than solving all the use cases I am given. (While obvious, I didn’t properly do the latter in all the interviews.)
      3. Security requirements.
   2. Non-functional requirements, give numbers where possible:
      1. Availability vs consistency: what matters more?
         1. Availability, but don’t discuss if some components can have lower availability. (No one wants to design a low availability system in an interview.)
         2. Consistency: strong vs eventual.
            1. Can some operations be asynchronous?
      2. Latency.
      3. End to end latency for an operation. For e.g., if an event enters your system, how soon do you want to process it and present results to end users?
   3. Design considerations.
2. Back-of-the-envelope estimation: only do those that make sense for the question. Examples:
   1. If there are mobile users, estimate data size.
3. API design.
4. High level design.
   1. Standard stuff:
      1. Telemetry (i.e. logging and metrics).

Based on interview’s choice:

1. Dig deeper into 2-3 components as required.
2. Failure handling.
3. Identify and resolve bottlenecks.
4. Database schema.
5. Back-of-the-envelope estimation.
   1. Assume designing a system for 5 years. (5 years = 60 months, so easier than 3 years = 36 months.)
   2. Data and cache storage.
   3. Traffic:
      1. Request rate.
      2. Bandwidth. (Probably tricky to estimate, so skip.)

Other things to keep in mind:

1. Write a lot and don’t assume interviewers are following everything you are saying. Use bullet points.