在設計互聯網服務的系統時，面向的是海量的互聯網用戶，尤其是對於擁有良好推廣渠道、不用花費太長時間進行推廣的互聯網產品，可能在系統上線之初就會進入大量用戶。因此需要預先估計系統的容量，作爲產品推廣、放量的依據；並且預先知道系統的瓶頸在哪、需要優先優化的方向、硬件需求取向、擴容的時機和規模。
典型的系統架構會有三層，分別是接入層、邏輯處理層、存儲層。對於接入層的機器而言，一般是不負責任何邏輯處理，也不保存業務狀態，因此對內存、外存沒有太高要求，CPU 採用普通檔次的即可，重要的是提供高帶寬的網卡。對於負責業務邏輯處理的機器，CPU、內存資源更爲重要。對於存儲機器，需要儘可能快的外存，並且對機器的可靠性要求較高。
對大文件存儲的應用來說，主要受限於外存的順序讀寫性能，一般用 MBPS 考察；對於小型的數據存取應用來說，主要首先於外存的隨機讀寫性能，一般用 IOPS 考察。7200轉的硬盤，順序讀能力不超過150MB/s，順序寫能力不超過70MB/s；隨機讀寫能力在 100 IOps 上下。因此，硬盤的性能對於順序讀寫海量數據的應用來說是足夠的，但是隨機訪問微小數據時，硬盤的機械特性就成了很嚴重的問題（需要先尋道，再讀寫，尋道時間爲ms級）。以上面假想的硬盤指標計算，每天最多可以順序讀取約13TB的數據，寫入約6.5TB的數據；或者執行800多萬次隨機IO。類似的，現在很火的 SSD 也可以如此計算。從 SSD 的單位容量成本看來，它不適合海量存儲，從性能指標看來，和機械硬盤相比順序讀寫的優勢也不是太大，但是隨機讀寫能力遠遠超過機械硬盤。
CPU 的性能指標是 IPS，最關鍵的指標是 CPU 的主頻，決定了每秒最多能執行的指令的數目，這樣就能知道 CPU 實際能承載的上限。在實際環境中，也可以通過觀察在線系統的 CPU 使用率和當前系統使用量，估計出 CPU 的容量有多大。
內存有兩方面的作用，一是提供業務處理所需要的存儲空間，二是作爲緩存。業務執行所需要的空間是臨時性的，可以很快回收復用，只要分配的速度不是太快以至於這部分空間不夠用即可。
系統中的緩存會長期佔用內存空間，是使用內存的大戶。計算緩存的大小，要知道被緩存數據的單位大小，以及所緩存的數據總數。在 Java 中，基本類型的大小是固定的，數據需要3個引用的額外開銷，對象需要兩個引用的額外開銷，在組成高一級的數據結構（對象）時，JVM 會將以8字節爲邊界單位進行數據對齊操作。有關 Java 對象大小計算的文章可以參考《HOWTO: Determine the size of a Java Object or Class》。
還需要考慮業務執行時可以分配的最大線程數量。Linux 上的線程堆棧最大可以佔用8MB內存空間，在 JVM 上可以通過啓動參數配置線程堆棧的大小，只要不超過操作系統的限制即可。通過系統的總內存空間、緩存所需要的空間、應用運行所需要的臨時空間，也就可以計算出線程數的限制。
網卡也是系統的限制之一，計算帶寬可以通過以下公式：(請求或者回應平均大小 * 請求數) / 86400s / 8bit
請求或者回應的平均大小可以在實際環境中採集得到，也可以通過業務的數據情況計算得到上限和平均值。需要注意的是，需要支持多對列的網卡和相應的 Linux kernel 才能利用多CPU/多核，否則所有的網絡 IO 開銷都會集中在一顆 CPU 上，使得無法足夠利用網卡的帶寬。
從遠程接口耗時計算系統的容量是比較簡單的。變量是接口的耗時，可以在實際環境上採集數據得到。
計算請求數的公式：(1s / 請求平均耗時) * 線程數 * 86400s
需要注意的是，外部接口後面往往是另外一套複雜的系統，越複雜的東西越容器出錯，而且自身系統到外部系統之間可能會經過可靠性較低的網絡，數據傳輸過程中的失敗率也會比較高，所以需要考慮在最糟糕的情況下如果處理，避免因爲遠程接口調用的失敗率過高造成系統雪崩。
計算系統容量不是一個太容易的過程，需要開發人員對系統的軟硬件都有較深入的瞭解，通過系統的物理限制得出程序所能提供吞吐量的上限。但是一旦掌握了計算的方法，就更容易做到對系統的能力心中有數，知道系統改進的方向，而不是盲人摸象般地開發或者重構。