對服務端應用而言，系統的伸縮性是最基本的需求。這就意味着系統應該是分佈式的，併發的。一個理想的可伸縮性架構應該將分佈式，併發的特徵對上層應用隱藏，儘管完全隱藏這些特徵不現實，而且需要上層應用的開發者遵循一定的編程模型(例如反應式的)，但開發者無需將較多的精力放在伸縮性架構的具體實現，而是遵守這樣的架構並重點關注應用邏輯的實現方面。
作者以遊戲項目爲例介紹了兩種伸縮性架構方案，一種是將遊戲基於地理位置分不同區域實現的，每個區域彼此獨立，限定地理區域的大小，這樣服務器就不會因爲太多用戶進入這個區域而擁塞，但這種方案需在開發/部署的時候決定哪些區域應該放在一臺服務器上；另一種方法是分區。一個分區是該區域的一份副本，運行在它自己的服務器上，獨立於其他的分區。這樣增加副本就增加了該區域允許的用戶數，但這種方案的缺點是不同分區彼此獨立，導致不同分區間的玩家彼此之間不能交互。
對於一個複雜的系統，用一組相互聯繫的服務來構建，“分而治之”是最基本的方法。每種服務都可以用一個接口來描述，這讓使用該服務的程序不會受到底層實現變更的影響，同時也支持這些實現可以獨立地完成。常見的幾個核心服務：數據服務、任務服務、會話服務、通道服務
數據服務應該是分佈式系統最基本的服務和難點。一個分佈式系統中往往又需要保持數據的一致性，這就需要提供集中式的數據服務，也就帶來數據資源訪問和操作的競爭問題，從而可能導致系統的性能瓶頸。對數據服務的設計需要充分考慮數據的特點，例如數據的讀寫頻度，更新頻度，生命週期等，只有把這些數據特點分析清楚後纔可能設計出合適的數據服務。
任務服務用於調度或執行任務。這些任務要麼是響應從客戶端收到的某個事件，要麼是服務器本身的內部邏輯發起的。
會話服務是在登錄和認證後，客戶端與服務器之間建立的一種聯繫。通過會話機制嚮應用層隱藏了客戶端和服務器的真實端點，同時會話服務也需要負責確保維持消息的順序。如果來自某個客戶端的前一條消息所引發的任務還沒有完成，後一條消息就不會提交，從而大大簡化了任務服務
通道服務在作者的項目中是一種一對多的通信機制。在概念上，通道可以由任何數目的客戶端加入，任何發往該通道的消息都會送達所有與通道相關的客戶端。
除了這些核心的服務，分佈式系統還需要負載均衡機制，將系統的服務請求根據一定策略分發/轉移到系統中各個節點