Planning the System Design Interviews

Introduction

System design interviews can feel overwhelming, but with a structured approach, they become manageable. Over the years I have taken more than 100 interviews and given more than 50 myself, and I've found that breaking the process down into clear steps not only helps in the interview but also improves real-world system design skills.

Before we begin, I will suggest the readers to get comfortable with whiteboarding tools like Draw.io, Excalidraw, Google Drawings, etc. Most companies will either bring their own tool or allow you to share your screen while using either of these tools. Getting comfortable with these will help you save a lot of time, believe me every second counts.

Since system design interviews are open-ended and have to be led by the candidate, it becomes imperative to lead the conversation in a structured manner, so you don't go back and forth with design,apis, database, technologies, etc.

Let's discuss how to approach these interviews effectively.

1. Understanding the Problem

The first and most crucial step is to thoroughly analyze the problem statement and write it down. Many candidates rush into designing without fully understanding what needs to be built—this can lead to poor solutions.

Before you dive in, ask yourself:

What are the core requirements? Clarify any ambiguous details with the interviewer.
What are the constraints? These guide your design choices.
What are the goals? Optimize for scalability? Low latency? High availability?

Many times I have been asked to design systems I have not heard before, The first step I took was to understand the problem statement by asking clarifying questions. It helped me understand the scope of the problem. Then i converted it to functional and non-functional requirements.

Functional Requirements

Clearly define what the system must do:

Identify the essential functionalities.
Discuss with the interviewer what is in-scope and what is out of scope.
Write it down to understand the clear scope of the problem.
For user facing products like Instagram, Whatsapp, etc. , requirements can begin like.
As a user, I should be able to...
For backend design like Notification Service, Scheduler service, requirements can begin like.
System should be able to...

Non-Functional Requirements

Beyond functionality, systems have to be:

Follow CAP theorem
Talk about what will you choose between Availability or Consistency w.r.t. the system you are designing.
Scalable (Can it handle millions of users?)
Reliable (What happens if a server crashes? Fault tolerance?)
Secure (How do we prevent unauthorized access?)

IMPORTANT

Tailor the non-functional requirements (NFRs) to the problem at hand. Avoid generic statements!
Example: For Instagram’s feed system, the initial page load time should be under 300 ms to ensure a smooth user experience.

I have been asked to tell the latency in numbers instead of "low latency" which is a relative term which helps in focussing on real world scenarios assuming the requirements based on that. Same goes for consistency and availability, ensure you know what you are saying in depth, what would consistency or availability mean in your system.

2. Capacity Estimation

System design is not just about drawing boxes and arrows—it requires back-of-the-envelope calculations. You should estimate:

Requests per second (RPS)
Storage requirements
Network bandwidth usage
Peak vs. normal load

This helps in making informed choices about database selection, caching, and horizontal scaling.
Below is an image of the latency numbers every programmer should know

I always ask the interviewer if he/she is interested in knowing the estimation. If the question asked is quite common,it's good to provide these numbers If not, postpone this during your high level design or even wrapping up to conserve time.

3. Core Entity Design

Identify the core components of your system and determine:

Core entities generally refer to the tables that you will create, think of them as data models or Java classes
For example, in an Uber-like system core entities can be User, Rider, Cab, etc.
Discuss all parameters of the entities w.r.t the system you are building.

IMPORTANT

This is where you can also discuss what database you will choose SQL vs NOSQL and the reasoning behind it.

4. API Design Discussions

APIs define how components interact. When designing APIs, consider:

Endpoints (REST, GraphQL, gRPC?)
Request & Response formats (JSON, Protobuf?)
Ensure how each API will satisfy the functional requirements.

TIP

The functional requirements should drive this conversation, if you got those right. You only have to define the APIs according to those.

At this point, I usually check the time and ask the interviewer if I should start the design. Most of the time, I write this down since my design revolves around the system’s APIs. But if the interviewer is more interested in the overall architecture, I skip this step.

5. High-Level System Design

This is where you sketch the overall architecture:

What are the major components? (Database, Cache, Load Balancer, etc.)
How do they interact?
What trade-offs are you making?
Rate limiting (To prevent abuse)
Error handling (Graceful degradation matters!)
Authentication & Authorization (OAuth, JWT, API keys?)

TIP

Usually you can skip Rate limiting, authentication by adding API gateway and ask interviewer if that's something he/she is interested in discussing. Most of the time interviewers will skip that since it's not part of the main design they are looking for, however it does not mean that you don't have to read about it.

TIP

Focus on conceptual understanding rather than low-level implementation details.
Example: When designing a ride-sharing service like Uber, discuss how drivers and riders are matched rather than dive into exact database schemas.

I always start implementing the apis discussed in previous steps. If you don't have enough time to write the apis, start with the functional requirements. Like for a news feed generation system. You can focus on how feeds will be ingested, how the recommendations will work, how users will view it. This gives a structured design approach and helps you identify what interviewer is most interested in discussing.

6. Deep Dive into Key Components

This is not a separate section as such, the design discussion itself will be covering breadth and depth of specific sections. So the interviewer may ask you to zoom in on specific parts:

How will the database be sharded?
How does the caching strategy work?
How will you handle concurrent requests?

And more follow-up questions, this is where you need to show the experience you have with a particular technology/design patterns, etc.

IMPORTANT

Sometimes these discussions are result defining since the interviewer gets to know if, what you have been discussing is all theoretical or you understand the tech as well.

TIP

Below discussions can be one or two liners where you explain critical parts of the system and how you would use monitoring, etc. Depending on the time and interest of the interviewer you can discuss them.

Fault Tolerance & Disaster Recovery

If you have discussed your overall design, the next thing you should discuss is about failures, since Failures will happen and your system should handle them gracefully:

Load balancing for redundancy
Database replication for failover
Auto-scaling to handle traffic spikes
Circuit-breaker to handle microservices failure.
A well-designed system should not have a single point of failure.

Monitoring & Logging

A system without monitoring is a black box. Implement:

Real-time alerts (Prometheus, Datadog)
Centralized logging (ELK Stack, CloudWatch)
Tracing to debug slow requests (OpenTelemetry)

Security & Authentication

A secure system is a trustworthy system. Consider:

Data encryption (at rest & in transit)
Role-based access control (RBAC)
Protection against common attacks (DDoS, SQL Injection, CSRF)

I have usually explained how I can add authentication (via OAUTH), etc since I have recently worked on it, but it's never a thorough discussion unless the interviewer wants to know about it. Same goes for monitoring/alerting. If you are aware about how these things work in a real world system that's usually enough for discussion on a high level. Since by this time interviewer has mostly made up his/her mind about hiring/not hiring the candidate.

7. Wrap-Up Discussion

Finally, summarize your approach :

Reiterate key design choices (and justify them)
Address trade-offs (e.g., latency vs. consistency)
Be open to feedback (Interviewers often test your flexibility)

Final Thoughts

System design interviews are not about memorizing architectures but about problem-solving and trade-offs. The more you practice, the better you'll get at:

Asking the right questions
Structuring your thoughts clearly
Balancing scalability, performance, and simplicity
Managing time is the key in a system design interview, if you spend more time than it is required it will have an impact on the design. In my experience, it's always good to do a quick time check with the interviewer and get feedback to either continue what you are explaining or focus on something the interviewer is interested to know

🚀 Good luck with your system design interviews! 🚀