System Design Interview Framework

From the co-founder of www.hellointerview.com

Evan King
5 min readNov 19, 2024

The easiest way to sabotage your chances of getting an offer in your system design interview is to fail to deliver a working system. This is the most common reason that mid-level candidates fail these interviews. While a firm structure to your approach is important and your interviewer is not trained specifically to assess you on your delivery (often this gets bucketed into “communication”), in practice we’ve seen many candidates that perform significantly better by following a structure which both keeps them from getting stuck and ensures they deliver a working system.

Requirements (~5 minutes)

The goal of the requirements section is to get a clear understanding of the system that you are being asked to design. To do this, we suggest you break your requirements into two sections.

1) Functional Requirements

Functional requirements are your “Users/Clients should be able to…” statements. These are the core features of your system and should be the first thing you discuss with your interviewer. Oftentimes this is a back and fourth with your interviewer. Ask targeted questions as if you were talking to a client, customer, or product manager (“does the system need to do X?”, “what would happen if Y?”) to arrive at a prioritized list of core features.

For example, if you were designing a system like Twitter, you might have the following functional requirements:

  • Users should be able to post tweets
  • Users should be able to follow other users
  • Users should be able to see tweets from users they follow

A cache meanwhile might have requirements like:

  • Clients should be able to insert items
  • Clients should be able to set expirations
  • Clients should be able to read items

Keep your requirements targeted! The main objective in the remaining part of the interview is to develop a system that meets the requirements you’ve identified — so it’s crucial to be strategic in your prioritization. Many of these systems have hundreds of features, but it’s your job to identify and prioritize the top 3. Having a long list of requirements will hurt you more than it will help you and many top FAANGs directly evaluate you on your ability to focus on what matters.

2) Non-functional Requirements

Non-functional requirements are statements about the system qualities that are important to your users. These can be phrased as “The system should be able to…” or “The system should be…” statements.

For example, if you were designing a system like Twitter, you might have the following non-functional requirements:

  • The system should be highly availability, prioritizing availability over consistency
  • The system should be able to scale to support 100M+ DAUs
  • The system should be low latency, rendering feeds in under 200ms

It’s important that non-functional requirements are put in the context of the system and, where possible, are quantified. For example, “the system should be low latency” is obvious and not very meaningful — nearly all systems should be low latency. “The system should have low latency search, < 500ms,” is much more useful as it identifies the part of the system that most needs to be low latency and provides a target.

Coming up with non-functional requirements can be challenging, especially if you’re not familiar with the domain. Here is a checklist of things to consider that might help you identify the most important non-functional requirements for your system. You’ll want to identify the top 3–5 that are most relevant to your system.

  1. CAP Theorem: Should your system prioritize consistency or availability? Note, partition tolerance is a given in distributed systems.
  2. Environment Constraints: Are there any constraints on the environment in which your system will run? For example, are you running on a mobile device with limited battery life? Running on devices with limited memory or limited bandwidth (e.g. streaming video on 3G)?
  3. Scalability: All systems need to scale, but does this system have unique scaling requirements? For example, does it have bursty traffic at a specific time of day? Are there events, like holidays, that will cause a significant increase in traffic? Also consider the read vs write ratio here. Does your system need to scale reads or writes more?
  4. Latency: How quickly does the system need to respond to user requests? Specifically consider any requests that require meaningful computation. For example, low latency search when designing Yelp.
  5. Durability: How important is it that the data in your system is not lost? For example, a social network might be able to tolerate some data loss, but a banking system cannot.
  6. Security: How secure does the system need to be? Consider data protection, access control, and compliance with regulations.
  7. Fault Tolerance: How well does the system need to handle failures? Consider redundancy, failover, and recovery mechanisms.
  8. Compliance: Are there legal or regulatory requirements the system needs to meet? Consider industry standards, data protection laws, and other regulations.

3) Capacity Estimation

Many guides you’ve read will suggest doing back-of-the-envelope calculations at this stage. We believe this is often unnecessary. Instead, perform calculations only if they will directly influence your design. In most scenarios, you’re dealing with a large, distributed system — and it’s reasonable to assume as much. Many candidates will calculate storage, DAU, and QPS, only to conclude, “ok, so it’s a lot. Got it.” As interviewers, we gain nothing from this except that you can perform basic arithmetic.

Our suggestion is to explain to the interviewer that you would like to skip on estimations upfront and that you will do math while designing when/if necessary. When would it be necessary? Imagine you are designing a TopK system for trending topics in FB posts. You would want to estimate the number of topics you would expect to see, as this will influence whether you can use a single instance of a data structure like a min-heap or if you need to shard it across multiple instances, which will have a big impact on your design.

Regardless of how you end up using it in the interview, learning to estimate relevant quantities quickly will help you quick reason through design trade-offs in your design. Don’t worry if you’re not good at mental arithmetic under pressure, most people aren’t.

Head over to Hello Interview to continue reading!

(don’t worry, it’s totally free)

--

--

No responses yet