Web 分散式系統的容錯主要靠客戶端快取與伺服器複製達成。HTTP 等協定本身並未納入任何特殊的容錯或復原機制。不過，Web 的高可用性也仰賴在關鍵服務中使用普遍可得的冗餘技術——例如前面提過的 DNS 允許一次名稱查詢回傳多個位址。

在傳統 Web 系統中，容錯相對容易達成：伺服器是無狀態設計，提供的內容又往往是靜態的。

Web 服務的容錯#

Web 服務的情況類似：幾乎沒有引入新的或特殊的容錯技術。但應當認清，遮蔽故障與復原的問題在這裡可能嚴重得多：

• Web 服務支援廣域分散式交易，解法勢必得處理參與服務故障或通訊不可靠的情況。
• 更重要的是，Web 服務很容易出現複雜的呼叫圖（calling graphs）。許多 Web 系統的運算遵循簡單的兩層客戶端—伺服器呼叫慣例：客戶端呼叫伺服器，伺服器不需要額外的外部服務就算出回應——此時複製伺服器或部分依賴結果快取通常就能容錯。Web 服務則常是多層解法，伺服器同時也是客戶端：對伺服器套用複製，意味著呼叫方與被呼叫方都得處理「對複製對象的呼叫」，正如第 10 章討論過的複製物件。

拜占庭容錯服務作為客戶端#

對設計來處理拜占庭故障（Byzantine failures）的服務，問題更加惡化。元件複製在此扮演關鍵角色，客戶端執行的協定亦然；此外還得面對「拜占庭容錯（Byzantine fault-tolerant, BFT）服務需要充當另一個未複製服務的客戶端」的情況。Merideth 等人（2005）基於 Castro 與 Liskov 的 BFT 系統（第 11 章討論過）提出解法，需要處理三個議題：

• 對客戶端隱藏複製：BFT 服務的客戶端應把它看成就是另一個 Web 服務——服務內部的複製要對客戶端隱藏，回應也要適當處理。例如，假設 BFT 服務設計上最多容忍 k 個行程故障，客戶端就需要從至多 2k + 1 個回應中收集到 k + 1 個相同的答案。這類回應處理通常可以藏在客戶端 stub 裡，而 stub 可從 WSDL 規格自動產生。
• 充當客戶端時保證內部一致：BFT 服務呼叫外部服務時，必須處理「外部服務對不同副本回傳不同答案」的情況（例如外部服務本身正因故障障出錯）。各副本可能因此需要在既有的拜占庭容錯協定之外，再執行一個額外的協議（agreement）協定，執行完才把答案送回客戶端。
• 外部服務把 BFT 服務視為單一實體：外部服務不能只憑單一副本送來的請求就動作，必須收到來自不同副本的至少 k + 1 個相同請求才能繼續。

這三種情況對應三塊不同的軟體，需要整合進開發 Web 服務的工具組中。