電子商務系統中，訂單更新必須按原始順序套用，且後端一次處理一個請求，負載是可變的。哪種方法能確保有序且可擴展的處理？

正確答案是使用 pull 模式的 Pub/Sub 訂閱者，並使用資料儲存來管理排序。此方法利用 Pub/Sub 的訊息佇列特性來接收所有訂單更新，確保訊息不會丟失。透過 pull 模式，訂閱者可以控制訊息的處理速率，每次只拉取一個訊息進行處理，這符合「後端一次處理一個請求」的要求。資料儲存（例如 Cloud Firestore 或 Cloud Spanner）則用於在處理前或處理後管理和驗證訂單的原始順序，確保「訂單更新必須按原始順序套用」。這種組合提供了可擴展性，因為 Pub/Sub 可以處理高吞吐量，而訂閱者可以根據負載自動擴展或縮減。 WebSockets 和 REST 請求雖然可以傳輸數據，但它們本身不提供內建的訊息排序或保證一次處理一個請求的機制，需要額外的複雜邏輯來實現。使用 push 模式的 Pub/Sub 訂閱者會將訊息推送到預先設定的端點，這可能導致訊息同時到達，不符合「一次處理一個請求」的要求，且難以控制處理順序。