interview question: design twitter
before you answer this problem, you need to know what can counted as a “good answer”.
work solution(it must be workable)
special case: answer the question based on the different properties of the system we are about to design.
analysis: show them the process of analysis
trade off: it’s a part of analysis technically.
knowledge base: you need to know enough terms or techniques to solve this problem
the most important part for above five parts are analysis. so how to analysis following a general guideline?
scenario: asking clearly about the following attributes of the system we are about to design: what features do we need to have? what qps for the server to handle? and what’s the approximate dau?
services: split the big system into specific smaller services.
storage: how to storage and access those data: sql or nosql? what’s the file system should looks like?
scale: thinking about the future: how to handle possible problems when the dau surge in a short time? how to handle the special cases? how to optimize the system?
use twitter design as an example:
first s:
first part, about the functions of this app: what are the functions needs to be implemented? tweet/re-tweet, follow/unfollow, like/unlike, comment, search for tweets/users, looking for the personal page of current user and other users. how to manage feeds timeline? what is the difference for registered user and visitors?(just think about all the workflows of cozyou app)
second part is about the user we need to handle: about the number of visits we need to handle? what’s the daily active user? what’s the monthly active user.
then we choose the core functions we need to implement, because we only have limit times.
so the core functions for an app like twitter, are: login/register, post, timeline, news feed, follow/unfollow.
choose the core user-related perporties: concurrent user(dau * number of requests per user / number of seconds per day), peak number of request. read qps(300k for twitter)/ write qps(5k for twitter)
second s:
divide:
merge: merge the service with similar target
and finally, we have: user service{register/login}, tweet service(post, personal news feed, timeline), media service(photos and videos), friendship service:(follow/unfollow)
third s:
first, choose from sql/nosql, and file system. (and we choose them for every service instead of app)
then, make a detailed structure of tables.
程式==算法+資料結構
系統= = 服務 +儲存
fourth s:
scale contains two parts: optimize and maintenance.
part1 optimize: 解決設計缺陷（pull model or push model? normalize or de-normalize），增加更多功能(edit, ads)，增加特殊用例(users like donald trump, lebron james, or zombie users)
part2:maintenance: 系統的強健性(有一台伺服器或者資料庫挂了怎麼辦)/系統的可拓展性（如果流量暴增 該如何拓展）