System design
1、Design facebook mem cache
2骤铃、設計一個圖片分享app绩蜻， 討論了怎么實現(xiàn)image feed還有實現(xiàn)拍照獲得圖片
3、google photos app
4弟灼、Design Instagram
5、設計一個景區(qū)簽到系統(tǒng)冒黑，估計類似Yelp田绑，答主答了Geohash 之類的東西
6、加面的題目是設計單機版memcached
這個不是系統(tǒng)設計抡爹，我主要說了底層的設計掩驱，hashtable, lru，memory management冬竟，怎么處理高并發(fā)欧穴。可能這個題要看面試官怎么問泵殴，這個可以問很深我覺得
7涮帘、Design a tree of sensor?
8、design load balancer
9笑诅、Facebook API News Feed
10调缨、給一個坐標，返回和它距離k的所有建筑
https://www.1point3acres.com/bbs/forum.php?mod=viewthread&tid=536531
11吆你、用戶過去七天里聽的最多的十首歌
用戶每聽一首歌弦叶，就調(diào)用一次API: hit(userID，songID)妇多，設計一個系統(tǒng)伤哺，返回用戶最近7天聽過最多的歌
12、經(jīng)常被考的那道搜索自動補充
設計在線text autocomplete，要求reliability默责，low latency
13贬循、location based design. 類似yelp
asked to use quad-tree not geo hash)
He said geohash is not accurate, as close points might not have close geo hash - i think guad tree also have the same issue
14、Design a translation/internationalization service for an application/web service like FB.
設計一個類似網(wǎng)頁translator桃序。網(wǎng)頁的內(nèi)容需要根據(jù)不同的地區(qū)翻譯成該地區(qū)的語言杖虾。
follow up - 對于dynamic的內(nèi)容，如何實現(xiàn)
15媒熊、design leet?????????????????code, bottle neck?
discuss where is the bottle neck (compiler and runner), how to optimize (stateless, can be scaled out), queue ..., don't forget to mention security.
16奇适、設計類似利口的做題網(wǎng)站，每天可以提供若干次競賽芦鳍，用戶需要注冊之后登陸然后提交代碼嚷往，關鍵是要快速列出ranking page，這也是我工作的一部分柠衅，感覺這兩輪系統(tǒng)有點位我定制的感覺皮仁。
design instagram，面試官說這個是API design 不是system design
要設計的功能包括Post菲宴，view, 小頭像怎么存贷祈，如何like, 如何顯示like (liked by xxx and 50 others), 如何評論，如何顯示評論喝峦，如果網(wǎng)絡不好會有什么影響 (還有一些不記得了）
17势誊、怎么利用幾千臺機器做個crawler
大概根據(jù)我對crawler的理解說了，包括DHT谣蠢，DB設計粟耻，用task queue發(fā)布新的url，別的server來pull眉踱，還有一些估值什么的挤忙。
要求不重復下載，機器間通迅最少
重點是要注意處理URL的hash谈喳，不要重復crawl饭玲，考察點是Sharding
每臺機器bfs去crawl那些倒不是重點
這題我覺得可以用consistent hashing 的思路解決。每臺機器都有一個指定的URI叁执，設計一個hash function，能將url和機器的url的hash值平均分布在0~2^64中矮冬。每當一個機器獲取一個List<url>, 算每個url的hashcode 然后發(fā)給指定的機器谈宛。所以每個機器中有兩個表，一個是hashcode對應每個機器的表胎署，另一個表是已經(jīng)visited的url的map吆录。至于減少機器之間的通訊，不知道怎么弄琼牧。恢筝。哀卫。
如果在意速度不太在意精確可以試試bloomfilter + 參考mapreduce的partitioner 將類似的url發(fā)到指定的計算機上？ lz是怎么答得呢撬槽？
一點想法獻醜:?
思路從 BFS 延伸此改，但最關鍵的點就在於只有一個起點為開始
總不能讓所有機器都從這個起點算起，做去重侄柔，這樣會有大量的 conflict
所以我的思路是邊 BFS共啃，某些 neighbor link 就自己算，某些就分配到 nearby computers
然後整個 workload 就會用傳染的方式暂题，讓多臺機器並行去算?
但這個方法移剪，可能會有些機器根本就沒用到的狀況
簡單說就是併發(fā)度不夠，明明可以更快卻快不起來
為了改善這個算法
我想如果一開始就能知道由起點展開的完整圖薪者，那就可以最佳化
將 graph 平均拆分成幾塊 sub-graph
每個機器去算若干個 sub-graphs纵苛，這樣就能最大化利用到每臺機器
所以我的想法是:
一開始先用方法一 (某臺機器為起點，傳染方式給周遭) 這步來建圖言津，
1 billion 的 URL攻人，假設長度 100 字元，每個 graph node 跟 edge纺念，假設要 50 Bytes贝椿，那麼一個 node 需要 1 billion * (100 + 50)(bytes) = 150 GB
10k 機器，總 memory 為 2500 GB陷谱，要拿其中約 150 GB 存 graph烙博，綽綽有餘
接著用方法二來分配 workload 給所有機器並行下載 HTML
但有個問題是分配 workload 這步要怎麼切圖，這部分再請大老們分享一下思路烟逊，謝謝
18渣窜、設計怎么通過hashtag找posts，instgram為例宪躯。講了通常分別式系統(tǒng)的設計乔宿，怎么build index，sharding之類的
19访雪、design ads 投放系統(tǒng)详瑞，每個ads有bid，也有target臣缀，還有budget坝橡，最高的符合target的bid的ad將被推給user，如果還沒有超過budget的話
比如budget是不是必須要到了0了馬上不deliver這個ad了精置，還是可以用async的方式減少latency但是可能over deliver计寇，另外target這個地方，一種方式是全掃描，另外就是考慮加index番宁，還有就是利用類似decision tree的方式呢對于這個user所在的分類/group直接返回相應的一組ads（這個方法assume read》》write new ads）不過最基本的就是先分析要求元莫，其次high level end to end的design，然后試圖deep dive
20蝶押、design a dropbox/file-sharing system?
21踱蠢、日志收集系統(tǒng)
分布式收集，統(tǒng)一處理播聪， 可以參考一下臉熟的Scribe
22朽基、Type lookahead
設計search infra to return typeahead (mainly focused on the components after tokenization and query understanding, machine learning for ranking is not considered here)
23、design a photo synchronization app 感覺跟dropbox有點像
24离陶、sys design, given list of places, find all places within circular distances of requested point at x, y.
這題我回答的是geohash稼虎，但對方一直追究geohash角落問題，個人對location理解不深招刨，大家good luck
25霎俩、一個上傳/下載系統(tǒng)，支持圖片視頻之類
26沉眶、設計Facebook News Feed
27打却、Design infra and storage for posts with same keywords
28、Design search b?????????????????ar
29谎倔、Facebook Messanger
30柳击、Design a distributed block storage
30、Design Facebook search片习。比較常規(guī)的系統(tǒng)設計題捌肴，無非就是如何scale up，如何shard數(shù)據(jù)藕咏，如何handle突然變得popular的search
knight in a infitite chess board状知，輸出從起點到另一點的最短距離，有obstacle孽查。BF?????????????????S饥悴。
33、做題盲再，不是原題但類似西设。給個字符串”123456789“，要求插入”+-*“答朋，使得最后計算數(shù)字等于某個給定數(shù)字贷揽，輸出所有滿足條件的結(jié)果。dfs绿映。寫到最后他看起來不太高興：+12*3和12*3是等價的，要求只輸出一個。仔細問了時空復雜度及優(yōu)化叉弦。就做了這一題
34丐一、design一個http download lib。題目就這么長淹冰，具體需求都是自己去問他库车。我問了文件大小（MB~GB）樱拴、主要面向的使用場景（desktop下電影下圖片）柠衍，多job，允許用底層庫比如libcurl晶乔。我的思路是用一個thread pool去實現(xiàn)珍坊，API提供了兩種：callback式的和promise/future式的。最后一直扯到thread的scheduling正罢。阵漏。（android 題）
35、設計一個fb食堂的訂餐系統(tǒng) 員工和visitor可以從一個食堂order meals 訂單的信息需要persistent翻具。按照某章思路答履怯，問下用戶量 設計service和schema 比如meal可以存在no sql里，訂單信息和user信息可以存在sql里裆泳，怎么scale叹洲。我覺得可以參考怎么設計黑車吃（lbs部分除外）
設計一個非死不可員工自己用的訂菜外賣系統(tǒng)， 支持兩種用戶工禾，客人和參觀运提，然后一些預定分發(fā)功能等等
36、設計 Calenda帜篇。我忘了Event object除了time, user, 還有l(wèi)ocation也很重要糙捺。
use cases多了
recurring event
handle event conflit
send user notification ahead of event
37、實現(xiàn)一個搜索的功能笙隙，給定一個query洪灯，返回相關的documents。
38竟痰、給一個地點和一個距離签钩，和一大堆places，設計一個service返回這個距離內(nèi)所有的places坏快，重點focus在如何存儲這些places和如何query铅檩，以及如何把這么多數(shù)據(jù)分別存儲
39、設計一個在分布式集群環(huán)境下提交job的service
service本身有哪些可能失敗的地方莽鸿，如何解決
service如果提交job失敗昧旨，然后報錯是內(nèi)存不足拾给，怎么處理
40、nearest point of interest兔沃， geohashing
41蒋得、system design：design a Facebook scale chess game which you can play 1V1 with your friends, you can play multiple games on multiple devices with multiple friends together at the same time, you can undo your last mov?????????????????e before the other player takes the move
在資料庫裡不需要存棋盤，只需要跟ＣＨＡＴ一樣存對話就好乒疏，比方說：
Game 12345
===========
Msg id 1 | Player A | (0,0) -> (0,1)
Msg id 2 | Player B | (7,0) -> (6,0)
Msg id 3 | Player A | (0,1) -> (0,2)
Msg id 4 | Player A | revert
Msg id 5 | Player A | revert
Msg id 6 | Player B | (6,0) -> (5,0)
因為棋盤跟規(guī)則是固定的额衙，ＬＯＡＤ ＧＡＭＥ的時後只需要重放操作（無效的操作會被skip比方說msg id 5)，在local/device上cache棋盤根已經(jīng)播放到哪一步就好怕吴。
剩下的就跟chat system 一樣
棋盤就是用8*8的2D array存就行了窍侧，應該還可以再壓縮點，然后感覺就和Design chat app的套路差不多了转绷。
感覺難點是undo your last move 如何處理race conditions
fb不考OOD的吧伟件，我在想題目說 play multiple games on multiple devices with multiple friends together at the same time, 和device有什么關系，另外是不是要考多線程暇咆？
我也覺得跟design chat 差不多 差別在一個group 只有兩個人 但是undo last move 感覺不用care race condition 因為輪流turn 一定自你的turn 才能ondo, 既然棋盤都能存了 感覺問題不大?
42锋爪、design the newsfeed product, focus on the API design and front-end integration, ?????????????????need to support web browser, smartphone and feature phone, etc. how to optimise for different devices to have a good user experience?
43、設計100K的web服務器到10K(1000qps)搜索服務器的最佳通訊方式爸业，利用load balancer或者message queue來做其骄，我是第一次onsite system design，直接懵了扯旷，恰好自己在做類似的工作拯爽，所以直接按照工作經(jīng)驗在找最好的解決方案，快結(jié)束的時候才想起來這是面試要多交流钧忽，多問問題毯炮，但是已經(jīng)完了，估計國人小哥當時也是懵了耸黑，給的數(shù)據(jù)基本上都沒怎么用上
44桃煎、 design friend list online and offline feature
簡單的思路：
assumption: 針對的use-case是用戶的朋友數(shù)量在1~1000個的情況，通常fB也限制朋友的最大數(shù)大刊。
1在用戶初次登陸的時候：從server讀取在線friend的列表为迈，并更新自己的online friend列表。同時缺菌，用戶的狀態(tài)由offline變成online也作為statuschange的消息push到server葫辐。
2當用戶在線使用fB的時候：朋友都有自己的狀態(tài)，如果一旦發(fā)生status change伴郁；把status change作為notification push到server耿战，然后轉(zhuǎn)給自己。例如焊傅，我正在使用fB剂陡，我的頁面上顯示了目前在線的friend狈涮，如果其中某個朋友下線了，他的狀態(tài)改變會通過notification push到server再轉(zhuǎn)給我鸭栖，或者直接notify我的client端薯嗤。
沒fB和系統(tǒng)架構(gòu)的經(jīng)驗，求拍纤泵！
你的思路對頭。 細節(jié)問的很細镜粤， 你的列表肯定存在緩存里捏题，比如redis， application server 可以直接fetch, 比如 schema 的設計肉渴， web server and data access server , DB and redis 具體如何同步公荧。可以zoom in 的很細同规。還有
DAU 給我的數(shù)據(jù)是 1billion 的用戶循狰。 我這沒設計過tps 這么高的系統(tǒng)。
感謝你把系統(tǒng)面試drill into這么細的程度券勺。給我進步思考的信息绪钥。
背景：我沒有設計和開發(fā)分布式系統(tǒng)的經(jīng)驗，目前正在看design data-intesnive application那本書关炼。同時在研究了很多論壇的總結(jié)帖子和油管的技術會議視頻程腹。我沒有太多經(jīng)驗，只能根據(jù)看這些資料來講我的理解了儒拂。
1. 緩存： 緩存的使用應該是比較直接寸潦，用戶登錄系統(tǒng)之后，web server通過緩存獲取自己全部信息（包括自己所有朋友列表）社痛，如果緩存沒有滴劲，就去route to dB獲取用戶信息洛波。在得到用戶自己的朋友列表之后，再去訪問另一個用戶狀態(tài)的緩存服務器（假設存在這樣一個用戶狀態(tài)緩存服務器）。假設用戶自己和朋友的社交網(wǎng)絡graph的地域分布特征為本區(qū)域和本國家內(nèi)的用戶的connect較密集动羽，國家之間、洲際之間用戶的connect較稀疏协屡； 所以這個用戶在線狀態(tài)緩存宫蛆，主要保存本地區(qū)用戶狀態(tài)。同時少量的其他國家统倒、地區(qū)的用戶在線狀態(tài),方便那些具有多國朋友的人查詢自己的好友是否在線寨典。
2. Schema的設計： 這里的schema，我理解的是用戶是否在線狀態(tài)的設計房匆，這個應該是in-Mem的schema-less的JSON對象耸成。如果只是為了online/offline這個應用报亩，在設計schema的時候只需要用少數(shù)幾個attribute，例如： userID井氢，userName弦追，country，Region etc 這樣也可以減少內(nèi)存需求空間花竞。至于臉書這個社交網(wǎng)絡平臺的其他schema的設計和考慮就比較寬了劲件，設計的內(nèi)容太多。
3. web server與data access server的同步：不知道需要討論那些問題约急。
4. 數(shù)據(jù)庫與緩存（例如Redis）的同步： 如我上面理解的零远，用戶在線狀態(tài)信息應該全部通過in-mem獲取，如果僅僅是確定在線好友狀態(tài)厌蔽，不用去訪問關系型數(shù)據(jù)庫（RMDB)牵辣。如果是其他信息的話，遵從先緩存更新奴饮，后RDMS更新的基本原則纬向。當然需要考慮讀/寫數(shù)據(jù)的request load來采取具體策略。
5. 1B的用戶數(shù)量： 還是需要考慮分片（sharding）戴卜。我前面假設臉書的用戶具有很明顯地域分布特征逾条。在分片的時候，主要考慮把本國本區(qū)域的人的在線狀態(tài)信息存儲在附近的datacenter投剥。
這五個方面我的理解肯定都比較膚淺膳帕。望樓主多多指教。也方便活躍版面熱烈討論技術的氛圍薇缅。
45危彩、design privacy content 是share 你的post 給specific group you want
46、design聊天軟件 不用考慮group chat和offline notification
47泳桦、design netflix
感謝你把系統(tǒng)面試drill into這么細的程度汤徽。給我進步思考的信息。
背景：我沒有設計和開發(fā)分布式系統(tǒng)的經(jīng)驗灸撰，目前正在看design data-intesnive application那本書谒府。同時在研究了很多論壇的總結(jié)帖子和油管的技術會議視頻。我沒有太多經(jīng)驗浮毯，只能根據(jù)看這些資料來講我的理解了完疫。
1. 緩存： 緩存的使用應該是比較直接，用戶登錄系統(tǒng)之后债蓝，web server通過緩存獲取自己全部信息（包括自己所有朋友列表）壳鹤，如果緩存沒有，就去route to dB獲取用戶信息饰迹。在得到用戶自己的朋友列表之后芳誓，再去訪問另一個用戶狀態(tài)的緩存服務器（假設存在這樣一個用戶狀態(tài)緩存服務器）余舶。假設用戶自己和朋友的社交網(wǎng)絡graph的地域分布特征為本區(qū)域和本國家內(nèi)的用戶的connect較密集，國家之間锹淌、洲際之間用戶的connect較稀疏匿值； 所以這個用戶在線狀態(tài)緩存，主要保存本地區(qū)用戶狀態(tài)赂摆。同時少量的其他國家挟憔、地區(qū)的用戶在線狀態(tài),方便那些具有多國朋友的人查詢自己的好友是否在線。
2. Schema的設計： 這里的schema烟号，我理解的是用戶是否在線狀態(tài)的設計曲楚，這個應該是in-Mem的schema-less的JSON對象。如果只是為了online/offline這個應用褥符，在設計schema的時候只需要用少數(shù)幾個attribute，例如： userID抚垃，userName喷楣，country，Region etc 這樣也可以減少內(nèi)存需求空間鹤树。至于臉書這個社交網(wǎng)絡平臺的其他schema的設計和考慮就比較寬了铣焊，設計的內(nèi)容太多。
3. web server與data access server的同步：不知道需要討論那些問題罕伯。
4. 數(shù)據(jù)庫與緩存（例如Redis）的同步： 如我上面理解的曲伊，用戶在線狀態(tài)信息應該全部通過in-mem獲取，如果僅僅是確定在線好友狀態(tài)追他，不用去訪問關系型數(shù)據(jù)庫（RMDB)坟募。如果是其他信息的話，遵從先緩存更新邑狸，后RDMS更新的基本原則懈糯。當然需要考慮讀/寫數(shù)據(jù)的request load來采取具體策略。
5. 1B的用戶數(shù)量： 還是需要考慮分片（sharding）单雾。我前面假設臉書的用戶具有很明顯地域分布特征赚哗。在分片的時候，主要考慮把本國本區(qū)域的人的在線狀態(tài)信息存儲在附近的datacenter硅堆。
這五個方面我的理解肯定都比較膚淺屿储。望樓主多多指教。也方便活躍版面熱烈討論技術的氛圍渐逃。
Design 總結(jié)：
https://www.1point3acres.com/bbs/forum.php?mod=viewthread&tid=537948
Design messaging system ---- 我覺得這個偏backend, 因為數(shù)據(jù)量比較大够掠，db設計也比較復雜，感覺后端很有考點茄菊。
Design instagram --- 這個我覺得像API design祖屏， 因為我覺得和news feed很像助赞。。袁勺。
Design news feed API --- 這個肯定是API咯雹食，
Design POI, Design typeahead --- 這兩個都用比較特別的data structure來存儲數(shù)據(jù) （quadtree/geohash, trie), 所以應該偏后端
Design web-crawler --- 這個應該也是后端， 因為本身就不是面對用戶的產(chǎn)品期丰。
Design memcache --- 這個應該也是后端
Design search system --- 這個像API群叶， 因為前端蠻多use case的， 覺得API有些講頭
Design internatlionalization service --- 這個也是API钝荡， db沒啥可講街立。。埠通。赎离。
Design leetcode ---?????????????????？端辱？梁剔？其實不知道這個題的requirement....
設計一個系統(tǒng), 返回用戶最近7天聽過最多的歌 --- 這個也像是backend, 因為use case比較單一，難點在后端
設計一個fb食堂的訂餐系統(tǒng) ---舞蔽？荣病？？渗柿？不知道个盆。。朵栖。颊亮。
Behavior:
最成功的項目；有跟別人有conflict嗎陨溅；最不喜歡跟什么樣的人work编兄；最喜歡組里的什么人，為什么声登；有什么失敗嗎狠鸳，學到了啥；
個人喜歡套 “舉個例子”?“所以我學到了blah blah”這個模板悯嗓，建議樓主去看看Dan Croitor的油管件舵，講得很詳細
1) dive deep into most recent project 2) most intestering debug/bug 3) describe most fav?????????????????orite day in your current company（呵呵）? 4) how to work across team 5) give me an example you push back 6) example you regret your design?
Culture fit 這輪真的非常重要。 千萬要重視起來脯厨。 如果是面E5铅祸。 一定要盡力往怎么lead project 上靠。 core values 也一定要記牢。
和同事conflict啊临梗，最proud的project啊之類的
e5 one system design
E6涡扼，兩輪設計
談經(jīng)驗 談leadership 談項目 談各種soft skills
HR mentioned:?
1. Show leadership in both ppl management and Project scope, in both experience and system design round
2. Clean code with test cases
3. System Design 里一定要主動driv?????????????????e這個chat 面試官會很希望你多問多想 他會幫助你narrow down這個題目的components
4. 在system面試里有機會可以dive deep into your domain knowledge. 如果你可以show一些面試官感興趣但是maybe也沒有很懂的東西 很有利于定級
NYC Onsite:
Timeline: coding1 + product desing + lunch + background + coding2 + coding3
常規(guī)behavior問題，聊proud的項目（問得很細盟庞，比如metrics）吃沪，如何處理和cowoker的沖突，等等什猖。這輪并不像recruiter說的會有一題coding票彪。
依然不知道怎么答比較好，最后面試官說：你說了太多detail不狮，我沒看出你是怎么從這些經(jīng)驗中學習的降铸，感覺涼了。全稱我采用了一個策略：我承認自己雖然目前情商不行摇零，但愿意學習推掸，最后問了他好多這個方面的問題，問他怎么學習這方面的能力的驻仅。他啪啪啪地記下來谅畅，感覺我的策略奏效了？
她問你有沒有過雾家，完成了一件事情后有如釋重負的感覺。樓主答的是most challenging绍豁，但這里她可能更想要我為什么覺得它很難芯咧，以及我的態(tài)度。
和同事老板conflict怎么樣竹揍，同事給你feedback有啥受益的么敬飒，老板好么怎么變得更好么，好員工有哪些品質(zhì)芬位？這個品質(zhì)你有嗎无拗，舉個例子啊。這是亞麻學的面試么昧碉，臉書也走這一套了英染。而且要求和亞麻一樣，例子要詳細被饿，技術細節(jié)上要面試官聽的懂四康，而且故事也要make sense，要面試官也同意你的做法是對的狭握。連說45分鐘闪金，很累。
why facebook
?one project that you are proud of/Team project/Disagreements/Constructive suggestions from manager 基本是地里常見的
bq 問了most proud project，project business value哎垦， internship 喜歡哪點 學到什么囱嫩， team conflict
常規(guī)bq，比較難的大概就是收到最有建設性的feedback是什么
第一輪：bq漏设。能記住的問題有：
1） 介紹驕傲的project墨闲。遇到了什么問題。
2） 怎么處理和manager的矛盾
3） 你有role model么愿题？是誰损俭？你覺得你和她的差距是什么？
問簡歷并且說的很具體潘酗。你收到的manager 的最差的feedback是什么杆兵。你最喜歡的教授和最討厭的教授。bq答的不是很好仔夺。
bq記得的有先說一個team work的project琐脏，然后講有沒有和隊友產(chǎn)生分歧以及解決方法，然后最proud的project缸兔，然后在team中有沒有其他隊員之間有沖突或者不engage你是怎么解決的日裙，還有最difficult的隊友
希望改進fb哪一點
最proud的項目；收到的positive的feedback是什么惰蜜；和其他team合作的經(jīng)歷昂拂；直接和客戶對需求的經(jīng)歷；和別人有分歧的經(jīng)歷抛猖；和別人有分歧但其實錯在自己的經(jīng)歷格侯；不太agree with的經(jīng)理的管理方式
Tell me about one of your successful projects.
What would you have done differently in this project?
Tell me the type of person you don't want to work with.
利口刷tag，高頻從上到下就夠了财著，我看了之前其他同學的面經(jīng)總結(jié)联四，高頻題都一樣，低頻的各不相同撑教，低頻碰上原題的概率極低朝墩，尤其是uday，幾十個人至少也得幾十個面試官伟姐。所以高頻準備好好的就行了收苏。
BQ: 最驕傲的project，為啥驕傲愤兵，如何convince others倒戏，如果能再做一遍這個project，你會改進什么地方
fav project / biggest challenge as in technology, communication, scale, people, etc / disagreement with manager, peers, ppl from other teams, how to solve at the end / what to expect at next job / least fav in work
bq各種least問題恐似，least internship杜跷， least person you work with,
https://www.1point3acres.com/bbs/thread-195416-1-1.html
---
經(jīng)驗：
結(jié)合我最近看design的資料，給樓主一點建議吧。
1 著重在thinking process葛闷，不要想45分鐘給一個完美的解決方案
2 條理要清晰憋槐，有big picture，有data modeling淑趾，有data flow
3 多從customer角度來考慮阳仔，用戶要什么知道了，你才好決定你的設計中的取舍
4 不要一開始就挖大坑扣泊，從MVP開始近范，最后時間足夠才加新的feature
5 從最開始簡單的架構(gòu)開始迭代，分析負載上去了之后的bottle neck在哪兒延蟹，你要怎么優(yōu)化评矩。這時候再帶入一點customer最關心的是哪里，可以做哪些tradeoff阱飘。你做這個技術選型的原因是什么斥杜，因為技術mature還是沒有spof
6 最后一定要review一下系統(tǒng)的scalability，負載x10的話沥匈，你的架構(gòu)是不是線性的加資源進去就好了蔗喂？
7 架構(gòu)確定好了之后，最好來個預估要達到這個性能指標高帖，我們需要多少機器以及怎么部署
8 別忘了提一嘴logging monitoring
9 扯一扯service oriented architecture也是極好的
10 把qconf 2012里scaling Pinterest from 0 to billions看幾遍缰儿，我看了那么多資料里面，最有啟發(fā)的一篇
總的來說散址，我不太建議一上去就擺一個高大上的架構(gòu)乖阵，從小到大循序漸進的來，你就可以展現(xiàn)你更多的能力爪飘，不光有breadth還有depth义起。系統(tǒng)設計都是相通的拉背，碰到?jīng)]見過沒準備的不要蒙蔽师崎，畢竟要考察的是思維過程，不是要求你設計一個完美解決方案椅棺。
我自己的系統(tǒng)設計套路：
1. 討論用戶是誰
2. 根據(jù)用戶討論feature
3. 問一下系統(tǒng)需要handle 的traffic, 問問需不需要進行計算犁罩。 面了8次系統(tǒng)設計，只有roblox 要求計算两疚。其他都不要床估。。诱渤。
4. 根據(jù)feature討論系統(tǒng)需要存儲和serve哪些data, 這些data用什么存丐巫， 討論sql/nosql/cache/object storage/hdfs 取舍， 巴拉巴拉。递胧。碑韵。
5. 根據(jù)數(shù)據(jù)， 設計service缎脾。 畫圖祝闻。
6. work through一個use case, 把所有service連起來， 同時修改剛才畫好的圖遗菠。 比如 做uber eats, 討論用戶要order 一個食物联喘，到餐館接到訂單， 到司機接到訂單辙纬。豁遭。。牲平。
7. 討論use case細節(jié)堤框， 比如 uber eats司機進入某個區(qū)域怎么識別啊， cache里怎么存啊纵柿。面試官全程都會drive你的design的蜈抓， 不會丟你在那里自言自語。
8. 面試官會問昂儒， 某些環(huán)節(jié)掛掉了沟使，怎么處理。 無非就是1. 要么replica渊跋， master slave, active-passive 或者 2.周期存snapshot 在磁盤上腊嗡，然后存action? log... 掛了可以重新恢復。拾酝。燕少。
9. 一些環(huán)節(jié)怎么scale... multi instance, partition 這些唄。蒿囤。 偶爾說說service mesh...
onsite面試經(jīng)驗：
- 我面的8次系統(tǒng)設計體驗都很好客们， 面試官會drive design全程， 他會不停的問你小問題帶你走材诽。 當然他也會根據(jù)你的設計不停的提出小問題底挫。 交流交流交流啦～
- 有的時候面試官會質(zhì)疑你的設計。 此時有兩種解法脸侥， 1. 解釋自己為什么這么做建邓， 讓面試官認同你的做法 2. 想一想是不是哪里做的不對， 面試官是不是再給你hint睁枕，要換一種設計官边。? 具體情況具體分析啦沸手。。注簿。
- 我至少3次面試罐氨，解釋了consistent hash 和 virtual node 怎么回事。滩援。? 不懂得朋友栅隐， 學學看哈。玩徊。
- 每個公司的系統(tǒng)設計面試題都蠻固定的租悄。 提前好好刷以下面經(jīng)，準備準備恩袱。
背景：我沒有設計和開發(fā)分布式系統(tǒng)的經(jīng)驗泣棋，目前正在看design data-intesnive application那本書。同時在研究了很多論壇的總結(jié)帖子和油管的技術會議視頻畔塔。我沒有太多經(jīng)驗潭辈，只能根據(jù)看這些資料來講我的理解了。
1. 緩存： 緩存的使用應該是比較直接澈吨，用戶登錄系統(tǒng)之后把敢，web server通過緩存獲取自己全部信息（包括自己所有朋友列表），如果緩存沒有谅辣，就去route to dB獲取用戶信息修赞。在得到用戶自己的朋友列表之后，再去訪問另一個用戶狀態(tài)的緩存服務器（假設存在這樣一個用戶狀態(tài)緩存服務器）桑阶。假設用戶自己和朋友的社交網(wǎng)絡graph的地域分布特征為本區(qū)域和本國家內(nèi)的用戶的connect較密集柏副，國家之間、洲際之間用戶的connect較稀疏蚣录； 所以這個用戶在線狀態(tài)緩存割择，主要保存本地區(qū)用戶狀態(tài)。同時少量的其他國家萎河、地區(qū)的用戶在線狀態(tài),方便那些具有多國朋友的人查詢自己的好友是否在線荔泳。
2. Schema的設計： 這里的schema，我理解的是用戶是否在線狀態(tài)的設計公壤，這個應該是in-Mem的schema-less的JSON對象换可。如果只是為了online/offline這個應用椎椰，在設計schema的時候只需要用少數(shù)幾個attribute厦幅，例如： userID，userName慨飘，country确憨，Region etc 這樣也可以減少內(nèi)存需求空間译荞。至于臉書這個社交網(wǎng)絡平臺的其他schema的設計和考慮就比較寬了，設計的內(nèi)容太多休弃。
3. web server與data access server的同步：不知道需要討論那些問題吞歼。
4. 數(shù)據(jù)庫與緩存（例如Redis）的同步： 如我上面理解的，用戶在線狀態(tài)信息應該全部通過in-mem獲取塔猾，如果僅僅是確定在線好友狀態(tài)篙骡，不用去訪問關系型數(shù)據(jù)庫（RMDB)。如果是其他信息的話丈甸，遵從先緩存更新糯俗，后RDMS更新的基本原則。當然需要考慮讀/寫數(shù)據(jù)的request load來采取具體策略睦擂。
5. 1B的用戶數(shù)量： 還是需要考慮分片（sharding）得湘。我前面假設臉書的用戶具有很明顯地域分布特征。在分片的時候顿仇，主要考慮把本國本區(qū)域的人的在線狀態(tài)信息存儲在附近的datacenter淘正。
