In the previous note: System Design Interview Tips, I mentioned how to perform better in a system design interview from the candidate’s perspective. In this note, we will use “Twitter” as an example to walk you through a complete system design interview.

Problem Statement

After some intro, the interviewer will kick start the interview with the definitions of some key features that Twitter is capable of:

• Post a tweet with less than 280 ASCII characters
• Follow/unfollow other users, no approval required
• Show User Timeline(UT): One user can see all tweets from another user.
• Show Home Timeline(HT): One user can see tweets from all users he/she follows.

Then, the interviewer will leave the candidate(TC) to drive the whole designing discussion.

Problem Exploration

This stage is neglected by in-experienced candidates quite often. However, the information collected at this stage typically has substantial impact on the architecture.

To gain that crystal clarity, the candidate needs to remind him/herself to ask questions around the Scale & User Behavior. For Twitter’s example:

• Total number of users: ~100M
• % of daily active users: ~10%
• % of users are READ ONLY: 95%
• % of users are posting daily: 5%, 1–5 tweets a day
• Avg ## of followers: ~100
• System latency tolerance: as fast as possible
• System consistency requirement: eventually consistent

These data points to a clear direction: Read latency optimization impacts the user experience most.

Handling Data

In most cases, drawing DB table schema is 1st step of the solution.

Here, TC needs to design at least 3 tables: User, Tweet and Home Timeline. User and Tweet table are obvious, either SQL or NoSQL works.

But, the design of HT table differentiate candidate’s design capability and set the foundation of entire solution.

Ideally, to minimize the reading latency at the scale of 10M DAU. The system that TC come up with should consist of:

• Pre-populated tweets in the HT for each user
• In-memory data storage which provides fastest read speed
• Multiple copies(redundancy) on different machines to avoid single point of failure while reading

If we try to match these requirements with the existing solutions we have in the market, No-SQL in-memory DB like Redis stands out.

#twitter #system-design-interview #software-development #computer-science #data science