一個付款服務從佇列消費「order placed」事件。由於系統在網路故障時會重試，同一事件偶爾會被投遞多次，導致顧客被重複收費。團隊應該採用哪一項設計原則，才能讓同一事件的重新處理不會改變結果？
本練習屬於課程
將理論付諸實踐，立即體驗我們的互動練習
學習雲端原生軟體的架構基礎。完成本章後，你將能在整體式架構、微服務、無伺服器與事件驅動模式之間做出選擇；理解緊耦合與鬆耦合、同步與非同步通訊的取捨；在無狀態服務中管理狀態；並以重試、指數退避、斷路器與死信佇列等方式設計韌性。
當前練習
在 Amazon API Gateway 上建置、保護並營運 API。完成本章後，你將能選擇正確的 API 類型（REST、HTTP 或 WebSocket）；設定具驗證與轉換的 Lambda 整合；使用 CloudFormation、SAM 與 CDK 將 API 部署到不同階段；並以 Amazon Cognito、IAM、Lambda 授權器、加密與節流機制來保護它們。
建置解耦、事件驅動與串流處理的工作負載。完成本章後，你將能使用 Amazon SQS 佇列（包含 FIFO 與死信佇列）與具訂閱篩選的 Amazon SNS 主題來解耦服務；使用 Amazon EventBridge 的規則、事件模式與結構將事件導流；以 Amazon Kinesis Data Streams 與 Data Firehose 處理高吞吐量資料；並以 Amazon DynamoDB Streams 即時回應資料表變更。
