Ace Your System Design Interview: Insider Tips From a Tech Industry Expert

The Ultimate Guide to Nailing Your System Design Interview.

System Design interviews are a crucial part of the technical interview process, especially for senior software engineering roles. These interviews assess a candidate’s ability to design large-scale distributed systems, which are essential for building robust and scalable applications. However, acing a system design interview can be challenging, especially if you’re not familiar with the process or the technical concepts involved.

In this article, I’ll be sharing the template that I followed to ace my system design interviews of tech giants like Flipkart and Phonepe among others. These steps are based on my personal experience and research. Whether you’re a seasoned engineer or just starting in your career, these tips and strategies will help you feel confident and prepared for your next system design interview.

By following this template, any system can be designed in an interview:

Clarify the problem

Make sure you understand the problem statement and ask clarifying questions if necessary.

Gather Requirements

Finalize on functional and non-functional requirements.

Functional

Functional requirements are the functionalities that the system or application can provide to the user. Example: In Twitter, a user can follow another user, tweet, like a tweet, retweet other’s tweet, and share a tweet (focus on the essential features and do not delve into the complex features of twitters)

Non-functional

For any distributed system, the following are the fundamental concepts to consider:

• High availability: Most of the systems must be highly available.
• Consistency: The systems with high availability will have eventual consistency. Any banking system favors consistency over availability as there cannot be discrepancies in data (account balance).
• Reliability: No loss of user data.
• Latency: Response time of a user action such as loading a web page, liking a post, etc.

Finalize on application scale.

Decide on the expected scale our application should perform on. This might affect the design and data storage decisions we will make.

Check Types of users for application (Optional)

Decide the actors/users for our application like Customers / Admins / Client Admins.

Finalize APIs to get a better understanding of query patterns.

Decide system’s input and output (By APIs), this provides clarity on how individual components should interact with each other.

Design Architecture

Identify the key components or modules that the system will consist of.
Create a high-level architecture for the system, including how the components will interact with each other. Initially start with a very basic design and then extend it.

• Extending the design — Creating specific components:
• Isolating the services — for easier scaling and traffic control
• Replicate the services and databases- mention about a single point of failure — Video
• Load balancer — Application side & Database side if needed — Video, Blog
• Message Queues — Tight coupling to loose coupling / Synchronous to Asynchronous communication — Read Message queues, Benefits of MQ
• Data Partitioning — Location-based, UserID based — Video, Blog
• Content Delivery network — To avoid round trips to the main server (reduces latency). Video, InterviewQs
• Cache — Distributed cache and client-side cache (For faster read access) — Video, Blog, Primer

Decide Database Structure for Microservices.

Database design for Microservices.

1. Separate DB for each service
2. Shared DB among all services

Important Database Patterns to Remember:

SAGA Pattern -> Maintain transaction property in microservices with each having separate DB.

CQRS Pattern -> Performing joins in microservices with each having separate DB.

Decide type for each database.

After discussing the data and the actions that a user can perform to interact with the system. The next step would be to talk about which type of DB you will use and your reasoning for using it.

Storage Estimation

• Based on the data modality: A rough estimate of how much data must be stored — To know what type of database can be used and file storage for storing images/videos.
• The number of requests to the service — To know how to scale the services. A service that is read-heavy can be scaled to handle high traffic of requests.
• Read Write ratio — Determines whether the system is read-heavy or not.

Points to consider for deciding database type:

1. Structure of Data (or Non Structured Data) / Schema.
2. Query Patterns.
3. Amount of Scaling needed.

Choice of Database:

1. Structured Data:
   — Need ACID -> RDBMS (MySQL, Oracle, PostgreSQL)
2. Non Structured Data:
   — Lots of Data Types (Columns) and lots of queries (Complex Queries) -> Document DB (MongoDB, Couchbase)
   — Ever Increasing Data (Exponentially increasing data) and Finite Queries (Less no. of queries) -> Columnar DB (Cassandra, HBase)

Other Storage Choices

For Cache -> Redis
For Blob Storage -> S3 + CDN
Text Search Engine -> Elastic Search or Solr
Append Only Write Mode, Bulk Read on time range -> TimeSeries DB (Grafana / Prometheus)
Data Warehouse -> Hadoop or RedShift

Scaling our Application

Consider how the system will scale in terms of traffic and user growth

1. Single Server
2. Application Server & DB Server Separation
3. Load Balancer + Multiple App Servers
4. Database Replication
5. Cache
6. CDN (Solve Latency Issue for faraway users)
7. Multiple Data Centres with Cross Replication
8. Message Queue
9. Database Scaling (by Sharding)

For read heavy systems, create separate service for read and writes

Additional components (optional)

These components can be added to the design if you have time left in the interview. Knowing about these components helps you answer any in-depth follow-up questions. Generally, the components mentioned above will suffice and also take most of your time in the interview.

• Encryption (messages) — for messaging services to secure data
• Analytics service — for analyzing requests and user data
• ML service — recommendation/ news feed ranking ( if use case (Netflix) demands then add it to the basic components) — talk about the data needed for your recommendation/ranking model.
• API gateway — Video, detailed microservices, and API gateway
• Service discovery — to dynamically identify microservices

Tip: The more questions you ask your interviewer the more inputs you’ll receive from the interviewer and the better your design will be.

Mainly think about how you can make your system fault-tolerant (system should be up and running at all times), and Scalable (to handle a growing amount of traffic). Brainstorm the bottlenecks and how they can be resolved.

Try to skip redundant info in interest of time.

Remember to think aloud and explain your thought process as you go through each of these steps.

I hope these tips and strategies will help you ace your next system design interview. If you enjoyed reading this article and want to stay updated with more useful content like this, be sure to follow me. I’ll be sharing more insights and advice on software engineering interviews, career development, and technology in general.
Don’t forget to clap and share this article with your friends and colleagues who might find it helpful. Good luck! Thanks for reading!