System Design Interview – An insider's guide

by Alex Xu

The ability to ask good questions is also an essential skill, and many interviewers specifically look for this skill.

A good interviewer also looks for red flags. Over-engineering is a real disease of many engineers as they delight in design purity and ignore tradeoffs.

a huge red flag as the interview is not a trivia contest. There is no right answer.

•What specific features are we going to build? •How many users does the product have? •How fast does the company anticipate to scale up? What are the anticipated scales in 3 months, 6 months, and a year? •What is the company’s technology stack? What existing services you might leverage to simplify the design?

•The interviewer might want you to identify the system bottlenecks and discuss potential improvements.

•Error cases (server failure, network loss, etc.) are interesting to talk about.

Dos •Always ask for clarification. Do not assume your assumption is correct. •Understand the requirements of the problem. •There is neither the right answer nor the best answer. A solution designed to solve the problems of a young startup is different from that of an established company with millions of users. Make sure you understand the requirements. •Let the interviewer know what you are thinking. Communicate with your interview. •Suggest multiple approaches if possible. •Once you agree with your interviewer on the blueprint, go into details on each component. Design the most critical components first. •Bounce ideas off the interviewer. A good interviewer works with you as a teammate. •Never give up. Don’ts •Don't be unprepared for typical interview questions. •Don’t jump into a solution without clarifying the requirements and assumptions. •Don’t go into too much detail on a single component in the beginning. Give the high-level design first then drills down. •If you get stuck, don't hesitate to ask for hints. •Again, communicate. Don't think in silence. •Don’t think your interview is done once you give the design. You are not done until your interviewer says you are done. Ask for feedback early and often.

•Building your own rate limiting service takes time. If you do not have enough engineering resources to implement a rate limiter, a commercial API gateway is a better option.

•Token bucket •Leaking bucket •Fixed window counter •Sliding window log •Sliding window counter

•It is usually necessary to have different buckets for different API endpoints. For instance, if a user is allowed to make 1 post per second, add 150 friends per day, and like 5 posts per second, 3 buckets are required for each user. •If we need to throttle requests based on IP addresses, each IP address requires a bucket. •If the system allows a maximum of 10,000 requests per second, it makes sense to have a global bucket shared by all requests.