Lots of people struggle with system design interviews (SDIs) primarily because of
- Unstructured nature of SDIs, where you’re asked to work on an open-ended design problem that doesn’t have a standard answer
- Your lack of experience in developing large scale systems and
- You’ve not spend enough time to prepare for SDIs.
Just like coding interviews, candidates who haven’t spent time preparing for SDIs mostly perform poorly. This gets aggravated when you’re interviewing at the top companies like Google, Facebook, Uber, etc. In these companies, if a candidate doesn’t perform above average, they have a limited chance to get an offer. On the other hand, a good performance always results in a better ffer (higher position and salary), since it reflects your ability to handle complex systems.
Solving system design questions could be broken down into several steps. Under each step, we’ll try to give examples of different design considerations for developing a Twitter-like service.
Step 1: Requirements clarifications
Always ask questions to find the exact scope of the problem you’re solving. Design questions are mostly open-ended, and they don’t have ONE correct answer, that’s why clarifying ambiguities early in the interview becomes critical. Candidates who spend enough time to clearly define the end goals of the system, always have a better chance to be successful in the interview. Also, since you only have 35-40 minutes to design a (supposedly) large system, you should clarify what parts of the system you would be focusing on.
- Will users of our service be able to post tweets and follow other people? Should we also design to create and display user’s timeline?Will tweets contain photos and videos?
- Are we focusing on backend only or are we developing front-end too? Will users be able to search tweets?
- Do we need to display hot trending topics? Would there be any push notification for new (or important) tweets?
All such question will determine how our end design will look like.
Step 2: System interface definition
Define what APIs are expected from the system. This would not only establish the exact contract expected from the system but would also ensure if you haven’t gotten any requirements wrong. Some examples for our Twitter-like service would be:
Step 3: Back-of-the-envelope estimation
It’s always a good idea to estimate the scale of the system you’re going to design. This would also help later when you’ll be focusing on scaling, partitioning, load balancing and caching.
- What scale is expected from the system (e.g., number of new tweets, number of tweet views, how many timeline generations per sec., etc.)?
- How much storage would we need? We’ll have different numbers if users can have photos and videos in their tweets.
- What network bandwidth usage are we expecting? This would be crucial in deciding how would we manage traffic and balance load between servers.
Step 4: Defining data model
Defining the data model early will clarify how data will ﬂow among different components of the system. Later, it will guide towards data partitioning and management. Candidate should be able to identify various entities of the system, how they will interact with each other and different aspect of data management like storage,transportation, encryption, etc. Here are some entities for our Twitter-like service:
- Which database system should we use? Would NoSQL like Cassandra best fits our needs, or we should use 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 core components of your system. You should identify enough components that are needed to solve the actual problem from end-to-end. For Twitter, at a high level, we would 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’ll 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 would also need a distributed file storage system for storing photos and videos.