4 Steps to solve any system design interview problem (With Examples)

Table of Contents

4 Steps To Solve Any System Design Problem with Examples

System design interviews are the toughest of all the interviews out there. The questions asked are ambiguous; there is no right or wrong answer. Unlike the whiteboard coding round, where you know that you have solved a problem correctly, in a system design round, there is no correct answer.

For a coding round, you might practice 100’s of different kinds of problems on websites like LeetCode, HackerRank etc. and clear the whiteboard coding round, but for system design, there is no such practice website.

In this article, we will be discussing four actionable steps for solving any system design interview problem and crack the system design interview.

Step 1: Clarify The Requirements

In a system design interview, the problem statement given by the interviewer is usually subjective and vague. For example, the interviewer might ask you to design a URL shortening service like TinyURL.

TinyURL is a website which was launched 18 years back! And might have many features that you don’t know about. Therefore, it is your job to clarify the features needed in the final MVP of the TinyURL clone that you are designing.

The best way to clarify a requirement is to try to break down the system’s requirements into functional and non-functional requirements. For example, the functional requirements here could be as follows:

Functional Requirements

  • Given a long URL, shorten it to at most 20 characters which will redirect to the long URL when trying to access it.
  • Functionality to pick a custom short URL instead of randomly generated URL.
  • Functionality to see the number of times a shortened URL is accessed

Non Functional Requirements

Some of the non-functional requirements could be:

  • The system should be highly available.
  • URL redirection should happen with minimal latency.
  • Service should be accessible over REST API’s
  • There can be a short delay of up to 5 minutes in updating URL statistics.

Remember, this is a crucial part of the interview. If you clarify the requirements incorrectly / or don’t even clarify the requirements, but just assume it, then your whole interview could be messed up and go in the wrong direction.

So, think about the product that you are designing from multiple angles and perspectives and clarify each requirement.

Step 2: Scope the Requirement

After clarifying the requirements, you should scope out the requirements. Scoping out the requirements means scoping out the scale at which you will be working, the kind of traffic you would be handling. Don’t ever skip this step! You and the person you are interviewing should be in total sync on the kind of load that the service needs to handle.

Based on the traffic of the service, you need to do some back of the envelope calculations to convert the traffic to estimate your storage needs and load. This number will significantly influence your design and technology choices later. Also, when done with the design, you will be justifying your design based on the calculations that you have done at this stage, so you must be clear with the scope of the system early on.

For example, for the URL shortening service like above, you could scope out the system like this below:


  • No of URLs shortened every day: 10M
  • No of URLs accessed every day: 200 M
  • Max Expiry Time: 5 years
  • Assuming an average growth rate of 10% (YoY): The peak traffic that we can expect at the end of 5 years will be 1.6 times current traffic. Therefore, we will design our system to handle that load.

Based on the above assumption, we can calculate the storage, traffic, and memory needs.

Traffic Requirements

  1. Total no of primary writes / second = 1.6 10M/ (243600) ~ 184 Writes/second (These are the writes caused due to shortening of long URLs). These writes must be immediate.
  2. Total no of secondary writes/second = 200 M / (24 * 3600) ~ 3707 K Writes / Second (We have a window of 5 minutes to perform these writes)

Storage Requirements

Since the max expiry time is five years, we must store the shortened URL and other statistics for each URL for five years.

  • The total no of URLs that we will be storing in 5 years will be 10M3651.6*5 = 29B URL’s
  • Assuming that each URL takes on an average 200 bytes of storage, the total requirement is 29B * 200 = 5.8TB .

    Memory Requirements

  • Total amount of data that is handled every day (For reads) = 1.6 200M 200 = 64GB
  • If 20% of the URLs cause us 80% of the traffic, we need to cache only 20% of the above memory. So the memory requirement for the cache is 20% of 64GB = 12.8 GB

    Step 3: Map Out the API Signature

    After scoping out the system, design the signatures of the API’s that you will be developing. This step is important, as before you start designing the system, you should have a concrete list and signature of the API’s that you will be designing.

    For example, for the URL shortening service example above, you could be developing a few APIs like this :

    1. ShortenURL(urlToBeShortened, customUrl = None, expire_date = None)
    2. GetStatistics(shortenedURL)

    Step 4: Divide the system into different components

    After the first three steps, you have a good idea of what you need to develop and what are the concrete goals that the design should meet. Therefore, it’s an excellent time to get into the actual design now.

    To start with the design, you can divide the whole design plan into different components and draw an architecture diagram to depict it.

    Database Design

    First, you should design the database schema for the database that you will be using. You should decide whether you are going to use a relational database or Non-Relational database for developing this system. Within relational and non-relational also, there are multiple choices of the databases available, you should decide which of them should be used for this system and what will be its schema.

    Load Balancers

    You should determine what load balancer to use and at what all places you will be using it. There are different types of load balancers suitable for different use-cases. You should think about that and make an informed choice.


    Since we decided to use cache to speed up the redirection process, we need to determine the type of cache that we are using. Will you increase replication b/w each caching server and what would be the cache policy?

    If you follow the above four steps, then the whole system design process will become manageable and easy to reason about and would help you in cracking the system design interview.

[gravityforms id="5" description="false" titla="false" ajax="true"]