Interview Template

This is an interview template and how long it would take in a typical interview.

Let's take a closer look at each one:

1. Clarify functional requirements

Ask:

• Which features are already covered by the existing services or APIs?
• Which features need to be built?

2. Go through non-functional requirements

Discuss with the interviewer any relevant requirements below:

Core 6:

• Scalability: Design the system to be able handle target number of users.
• Availability: Design the system to be operational when needed by using techniques like replication to avoid downtime.
• Latency: Identify the acceptable latency for the system. This varies depending on the application (e.g., Google Docs requires low latency, while Dropbox can handle longer latencies).
• Reliability: Ensure that the service consistently returns correct and expected results.
• Consistency: Address data consistency between services, ensure reading from different sources gives the same result, and decide where to save the data.
• Efficiency: Minimize redundant operations and optimize resource usage.

Special:

• Privacy: Consider GDPR compliance and other privacy requirements depending on the data being stored and processed (e.g., email, user information).

Put these requirements in the context of the problem being discussed.

3. Resource Estimation

Ask:

• How many daily users does the system need to support (i.e. Daily Active Users aka DAU)?
• How long should the data be stored (i.e. data retention)?

Estimate:

• QPS (Queries per second):
  • Read.
  • Write.
• Ongoing connections (if applicable), e.g., for WebSocket-based applications like WhatsApp.
• Throughput (in GB/s), needed for video streaming or image hosting problems.
• Storage requirements based on data retention and object byte sizing using the number of strings.
• Identify potential bottlenecks in the system, such as DB or QPS limitations.

4. API Endpoint Design

APIs establish a contract between the service and the end user. Usually in this part we want to specify REST API request and response interface. Note that we only care about the APIs related to the functional requirements and avoid introducing irrelevant APIs. This step can also be done after Step 5 high level design if the interviewer considers this to be too detailed.

If the system necessitates bidirectional communication, don't forget to discuss technologies that facilitate this, such as WebSockets, or server-to-client messaging protocols like Server-Sent Events.

5. High-level Design (Design Diagram)

Draw a high-level system diagram that includes:

• Main components of the systems and how they interact with each other.
• Data flow: Show how data moves through the system.
• Traffic pattern: If relevant to the problem, show how the system handles different types of traffic (e.g., push vs. pull for Twitter).
• Database model/schema, and which fields to index if necessary.

Make sure every feature in the functional requirements is covered in the design. However, don’t dive deep into the details too early at this point.

Note that, in most cases, when we're sketching out system design, we primarily focus on the key components that are specific to the unique problems the system is aiming to solve. Common elements like authentication, which are parts of virtually all systems, are often left out of these initial diagrams.

It's also essential to bear in mind that during the initial stages of system design, it's not typical to delve into the particulars of specific technologies. Over-emphasizing buzzwords or trendy tech stacks can be a significant misstep, as interviewers may perceive it as an attempt to cover up a lack of understanding of the fundamental concepts.

6. Detailed Design (Deep Dive)

The goal of this section is to identify the parts of the components in the system that could lead to (mostly scalability) problems and discuss how to handle them, possibly by modifying the design. This section is more open-ended and relies on interaction with the interviewer. Non-functional requirements play a key role in making design decisions here.

Once we identify a problem, we should propose ideally multiple solutions and discuss their trade-offs. The trade-offs are usually along the lines of balancing scalability, latency and consistency.

How System Design School’s Questions are Designed

As you can see, the interview format is quite open-ended. In System Design School’s question format, we have to introduce some constraints to the problems to make the answers more directed so we can provide more standardized answers and give you feedback. Therefore, Step 1 and 2 are defined for you in the problem description, and Steps 3-6 are for you to complete.