設計一系統涉及方方面面。下面我們單從性能方面描述設計的考慮。
解決軟件架構設計問題，我們遵循分而治之的方略。所以我們看到有橫向的劃分跟縱向的分層。這樣我們纔可能把問題各個擊破。
在業務層面上，我們可以考慮把系統拆分成子系統。子系統相對獨立並協調合作。自然我們可以考慮SOA。我這裏並不強調SOA的概念，核心強調的是業務的分拆。如果子系統可以單獨擴展，這樣在遇到瓶頸是就可以對相應的子系統進行擴展。 這樣子系統從數據庫，持久層，業務層，服務提供層都相對獨立開來。
再進一步我們考慮服務的部署。同樣我們要考慮各部件的邏輯獨立性。我們要清楚劃分邊界，Web服務器，應用服務器，數據庫服務器，文件服務器，消息中間件.....我們要儘量保證各組件的界地。這樣也是爲了我們擴展的靈活。可以在相應服務出現瓶頸時單獨擴展。
具體到各層應用的設計上，我們要考慮充分利用資源，同時考慮橫向跟縱向的擴展。
在資源利用上，我們常面臨I/O的瓶頸，從南橋（即系統I/O芯片（SI/O）：主要管理中低速外部設備；集成了中斷控制器、DMA控制器。）到網絡I/O。常常會成爲我們性能的瓶頸。在系統設計時，我們不能寄希望於相應資源的升級，提升。從軟件本身的角度出發，我們要考慮的是軟件的機制。我們可以合理的設計緩存來減少I/O。緩存的可以在系統的各個層次。從數據庫到客戶端瀏覽器爲了合理減少I/O，都有緩存的身影。引入一個方案能解決相應的問題，同時也要付出代價。緩存的引入勢必帶來數據一致性的問題。在設計時我們一定得歸類各種數據，不變的，常變的，偶變的。還有我們還要考慮應用對數據一致性的要求。從多個角度我們綜合分析是否 並如何引入緩存。
在說緩存的同時，我們要區分內存存儲。緩存跟內存存儲是有重要區別的。緩存並不保證被保存的數據一直存儲。記得在Infoq上有一個文章專門指出我們不能用memcache來存儲session。用他來存儲會導致某些用戶意外中斷連接，這就是由於memcache的本質所決定的，它作爲緩存並不保證對session的存儲。而session實際上要的是存儲。所以此文章建議用內存數據庫來保存session.
說了I/O,當然我們還要考慮其他資源的有效利用。CPU, memory等等。多進程，線程，並行程序設計必然是我們要考慮的。多進程，線程能充分利用我們的CPU的計算能力。當然同時也會帶來上下文切換的開銷。所以要綜合應用I/O的情況，來規劃。如果是計算密集型的應用，太多的進程，線程調度反而適得其反。
在I/O密集型的時候，當然可以考慮引入異步的計算。其實當下很多的reactive的平臺提供了很多異步的支持供我們取捨。
總之系統的無銀彈，我們得從各個角度綜合分析。