問題的復雜度要與解決問題的方法及成本相匹配；
規則一、避免過度設計
內容：在設計中要警惕復雜的解決方案
用法：通過測試同事是否能夠輕松地理解解決方案來驗證是否存在過度設計
原因：復雜的解決方案實施成本過高，而且長期的維護費用昂貴
要點：復雜的系統限制了擴展性。簡單的系統易維護，易擴展且成本低
例子：例如設計一款家用空調，室外可以達到熱力學溫度0K，在室內可以達到300F，這是在浪費資源且毫無必要。-20~30度，過度設計有過度使用資源的情況，包括為研發和實施硬件，軟件解決方案付出的較高費用。如果因為過度設計造成系統的研發周度過長，影響公司產品的發布計划。
規則二、方案中包括擴展
內容：提供及時可擴展性的DID方法
用法：Design(D)設計20倍的容量；Implement(I)實施3倍的容量；Deploy（D）部署1.5倍的容量
原因：DID為產品擴展提供了經濟，有效，及時的方法
要點：在早期考慮可擴展性可以幫助團隊節省時間和金錢。在需求發生大約一個月前實施（寫代碼），在客戶蜂擁而至的幾天前部署。
例子：“什么時候該在可擴展性上投入”有些輕率的回答是，最好在需要的前一天投入和部署。如果你能夠多做到達需要改善可擴展性方案的前一天部署，那么 這筆投資的時機最佳，而且有助於實現公司財務和股東利益的最大化。
讓我們面對現實，及時投入和部署根本就不可能，即使可能，也無法確定具體的時間，而且會帶來很多風險。DID（設計-實施-部署）：思考問題和設計方案，為方案構建系統和編寫代碼；實際安裝或者部署方案。
設計（Design）:DID方法的設計（D）階段聚集在擴展到20倍和無限大之間，通過如今可擴展性大會，把領導者和工程師團隊聚集在一起，共同討論產品的擴展瓶頸，這是在DID設計階段發現和確定需要擴展部分的一個好辦法。
實施（I，Implement）:我們把規模需求的范圍縮小到更接近現實，例如當前規模的3~20倍。
部署（D，Deploy）:在部署階段資產的成本較高，如果是一家適度高增長的公司，也許我們可以把最大產能提高到1.5倍；如果是一家超高增長的公司，也許我們可以把最大產能提高到5倍。擴展具有彈性，它既可以擴張也可以收縮，因此靈活性是關鍵，因為你需要響應客戶的請求，隨着規模的收縮和擴張，在系統之間調整容量。
規則3-三次簡化方案
內容：在設計復雜系統時，從項目的范圍、設計和實施角度簡化方案
用法：采用帕累托（Pareto）原則簡化范圍；考慮成本優化和可擴展性來簡化設計；依靠其他人的經驗來簡化部署；
原因：只聚焦“不過度復雜”，並不能解決需求或歷史發展與變革中的各種問題
要點：在產品研發的各個階段都需要做好簡化
例子：“問三個如何”：如何簡化方案范圍；如何簡化方案設計；如果簡化方案實施；
如何簡化方案范圍：
對這個簡化問題的答案是不斷的應用帕累托原則（也叫80-20原則）。收益的80%來自於20%的工作？對此，直接的問題是“你收入的80%是由哪些20%的功能實現的”，做得很少（工作的20%）同時取得顯著的效益（價值的80%），解放團隊去做其他的工作。如果刪除產品中不必要的功能，那么可以做五倍的工作，而且產品並沒有那么復雜！減少五分之四的功能，毫無疑問，系統將會減少功能之間的依賴關系，因而可以更高效率和更高本益比地進行擴展。此外釋放出的80%的時間可用於推出新產品，以及投資思考未來產品可擴展性的需求。
如何簡化方案設計：
簡化設計與過度設計的復雜性密切相關；簡化設計的步驟要求以易於理解，低成本，高效益和可擴展的方式來完成工作。
如何簡化方案實施：
如何利用其它經驗和已經存在的解決方案來簡化方案實施？
首先尋找被廣泛采用的開源或第三方解決方案來滿足需求；
其次看看在組織內是否有人准備了可擴展方案；
再次看看外部是否有人已經描述了一種可以合法復制或模仿的可擴展方案；
只有這三項都無合適的情況下，我們才會開始嘗試自己創建解決方案。
規則4-減少域名解析
內容：從用戶角度減少域名解析次數
場景：對性能敏感的所有網頁
用法：盡量減少下載頁面所需的域名解析次數，但要保持與瀏覽器的並發連接平衡；
原因：域名解析耗時而且大量解析會影響用戶體驗