System Design Interview might be a step in your hiring process for a new company, the company is trying to evaluate your skill at designing real-world software systems involving multiple components. these interviews are mainly for seniors as it's expected they have the sufficient and relevant industry experience to answer this type of question well.

What is the benefit of system design interview?

The system design interview simulates real-life problem solving where two co-workers collaborate on an ambiguous problem and come up with a solution that meets their goals. The problem is open-ended, and there is no perfect answer. The final design is less important compared to the work you put into the design process. This allows you to demonstrate your design skill, defend your design choices, and respond to feedback in a constructive manner.

Why do I struggle with system design interviews (SDIs) ?

there are three reasons for that :

• The unstructured nature of SDIs, where they are asked to work on an open-ended design problem that doesn’t have a standard answer.
• Their lack of experience in developing large-scale systems.
• you did not prepare for SDIs.

they are open-ended. Just like in the real world, there are many differences and variations in the system.
The desired outcome is to come up with an architecture to achieve system design goals.
The discussions could go in different ways depending on the interviewer. Some interviewers may choose high-level architecture to cover all aspects; whereas some might choose one or more areas to focus on. Typically, system requirements, constraints and bottlenecks should be well understood to shape the direction of both the interviewer and interviewee.

it's a skill and of course needs practice like coding interviews, if you didn't practice well you will perform poorly in interviews

What is an interviewer looking for in a system design interview?

the interview is not all about design skills. It is much more than that.

• An effective interview gives strong signals about a person's ability to collaborate, work under pressure, and resolve ambiguity constructively.
  The ability to ask good questions
  
• A good interviewer also looks for red flags. Over-engineering is a real disease of many engineers as they delight in design purity and ignore tradeoffs.

How I can perform in a system design interview?

We’ll follow a step by step framework to solve design problems.
First, let’s go through these steps:

Step 1: Requirements clarifications
Step 2: System interface definition
Step 3: Back-of-the-envelope estimation
Step 4: Defining data model
Step 5: High-level design
Step 6: Detailed design
Step 7: Identifying and resolving bottlenecks

Step 1: Requirements Clarifications

• ask about the exact scope of the problem, since we have limited time we should clarify what parts of the system we will be focusing on.
• clarifying ambiguities early in the interview is critical. Design questions are mostly open-ended, and they don’t have ONE correct answer.
• Slow down. Think deeply and ask questions to clarify requirements and assumptions. This is extremely important. giving out an answer quickly without thinking gives you no bonus points. Answering without a thorough understanding of the requirements is a huge red flag as the interview is not a trivia contest.

What kind of questions to ask? Ask questions to understand the exact requirements. Here is a list of questions to help you get started:

• What specific features are we going to build?
• How many users does the product have?
• How fast does the company anticipate to scale up? What are the anticipated scales in 3 months, 6 months, and a year?
• What is the company’s technology stack? What existing services you might leverage to simplify the design?

Let’s expand this with an actual example of designing a Twitter-like service. Here are some questions

for designing Twitter that should be answered before moving on to the next steps:

• Will users of our service be able to post tweets and follow other people?
• Should we also design to create and display the user’s timeline?
• Will tweets contain photos and videos?
• Are we focusing on the backend only or are we developing the front-end too?
• Will users be able to search tweets?
• Do we need to display hot trending topics?
• Will there be any push notifications for new (or important) tweets? All such questions will determine what our end design will look like.

Step 2: System Interface Definition

• Define the functional requirement:
  represent what functionality we want, what APIs are expected from the system, some examples for our Twitter-like service will be:
  

  postTweet(user_id, tweet_data, tweet_location, user_location, timestamp, …)
  generateTimeline(user_id, current_time, user_location, …)
  markTweetFavorite(user_id, tweet_id, timestamp, …)
  

• Define The Nonfunctional Requirements
  represent the behavior of this functionality on the system, Define how the system should perform, Some examples are
  

  The website pages should load in 3 seconds with the total number of simultaneous users < 5 thousand.
  The system should be able to handle 20 million users without performance deterioration.
  

Here’s a brief comparison

Nonfunctional Requirements Example

• High availability
• low latency
• consistency can take a bit -- or Eventually consistency

Availability: is the amount of time that a system is able to respond, that is the ratio of Uptime / (Uptime + Downtime). Availability is a critical metric of performance for a service

Latency: is the amount of time in milliseconds (ms) it takes a single message to be delivered. The concept can be applied to any aspect of a system where data is being requested and transferred.

Consistency:

• Strict consistency (immediate) states that for any incoming write operation, once a write is acknowledged to the client, the updated value is visible on reading from any replicated node (server) in the system. This effectively means that all readers are blocked until replication of the new data to all the nodes is complete.

• eventual consistency: is used in distributed computing to achieve high availability that informally guarantees that, if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value.

Step 3: Back-Of-The-Envelope Estimation

estimate the scale will help later when we will be focusing on scaling, partitioning, load balancing, and caching.

• What is the Expected Scale from the system (e.g., number of new tweets, number of tweet views, number of timeline generations per sec., etc.)?
• How much Storage will we need? We will have different numbers if users can have photos and videos in their tweets.
• What Network Bandwidth usage are we expecting? This will be crucial in deciding how we will manage traffic and balance load between servers.

Step 4: Defining Data Model

Defining the data model early will clarify how data will flow and will guide toward data partitioning and management. Identify various entities of the system, how they will interact with each other, and different aspects of data management like storage, transportation, encryption, etc.

Here are some entities for our Twitter-like service:
User: UserID, Name, Email, DoB, CreationData, LastLogin, etc.
Tweet: TweetID, Content, TweetLocation, NumberOfLikes, TimeStamp, etc.
UserFollow: UserdID1, UserID2
FavoriteTweets: UserID, TweetID, TimeStamp

Which database system should we use?
Will NoSQL like Cassandra best fit our needs, or should we use a MySQL-like solution?
What kind of block storage should we use to store photos and videos?

Step 5: High-Level Design

Draw a block diagram with 5-6 boxes representing the core components of our system.
For Twitter, we will need multiple application servers to serve all the read/write requests with load balancers in front of them for traffic distributions. If we’re assuming that we will have a lot more read traffic (as compared to write), we can decide to have separate servers for handling these scenarios. On the backend, we need an efficient database that can store all the tweets and can support a huge number of reads. We will also need a distributed file storage system for storing photos and videos.

Step 6: Detailed Design

Dig deeper into two or three components; the interviewer’s feedback should always guide us on what parts of the system need further discussion. We should be able to present different approaches, their pros and cons, and explain why we will prefer one approach over the other. Remember there is no single answer, the only important thing is to consider tradeoffs between different options while keeping the system constraints in mind.

• Since we will be storing a massive amount of data, how should we partition our data to distribute it to multiple databases? Should we try to store all the data of a user on the same database? What issue could it cause?
• How will we handle hot users who tweet a lot or follow lots of people?
• Since users’ timelines will contain the most recent (and relevant) tweets, should we try to store our data in such a way that is optimized for scanning the latest tweets?
• How much and at which layer should we introduce cache to speed things up?
• What components need better load balancing?

Step 7: Identifying And Resolving Bottlenecks

Try to discuss as many bottlenecks as possible and different approaches to mitigate them.

• Is there any single point of failure in our system? What are we doing to mitigate it?
• Do we have enough replicas of the data so that if we lose a few servers we can still serve our users?
• Similarly, do we have enough copies of different services running such that a few failures will not cause a total system shutdown?
• How are we monitoring the performance of our service? Do we get alerts whenever critical components fail or their performance degrades?

Summary

In short, preparation and being organized during the interview are the keys to being successful in system design interviews. The above-mentioned steps should guide you to remain on track and cover all the different aspects while designing a system.

Refs:

• Grokking the System Design Interview book by Design Gurus
• System Design Interview – An insider's guide by Alex Xu
• Functional and Nonfunctional Requirements: Specification and Types
• Latency, throughput, and availability: system design interview concepts (3 of 9)
• System Design Interview Concepts – Eventual Consistency