在啟動具有許多交互的社交應用程序時要避免的代碼和服務器陷阱？

Question

假設你想推出一個社交應用程序（這意味着許多交互），並希望獲得數千名用戶，對於那些已經這樣做的人，你知道哪些陷阱是你絕對要避免的，在代碼和服務器架構確定？

我有一種感覺，當你試圖回答這類問題時，你很容易感到孤獨，這顯然超出了所有 SaaS 或登陸頁面的范圍，這些頁面可能（我堅持這個詞）沒有這個擴展問題. 或者也許只是沒有真正的陷阱，最好的方法是“問題”->“解決方案”，當這些問題出現時。

我不認為這是一個基於意見的問題，因為 I/O 密集型數據庫、隊列系統、服務器計算等在這種配置中顯然有一些技術考慮。

給你一些我認為大型社交應用程序可能遇到的問題的例子，有 Facebook 工程師有他們的早期延遲問題，或者 Twitter 工程師有他們的 Bieber 問題。

我能夠避免 Netflix 無法避免的第一個陷阱，即不使用雲並嘗試以這種規模構建自己的服務器基礎設施。

Answer 1

CAP 定理對於所有大型分布式系統都是至關重要的。 它解釋here 。