只要系統會重試，就一定會有重複。冪等＝「同一操作做一次和做多次，結果一樣」——它是重試、at-least-once 訊息、網路逾時能安全運作的前提。
🧠 Core Ideas
TIP
冪等的核心情境：網路逾時時你根本不知道對方到底做了沒——只能重試。若操作不冪等，重試就會重複扣款、重複建單。把操作設計成冪等（或加去重機制），重試才安全。
- RPC / 網路請求可能逾時而無結果，重試可能造成重複執行——除非有冪等機制。
- 訊息佇列的 at-least-once 投遞不掉訊息但可能重送 → 消費端必須冪等。
- 「exactly-once」成本高，實務多用 at-least-once + 冪等消費者去逼近。
⚖️ Tradeoffs
哪些天生冪等、哪些不是
- 天生冪等：讀取、把值設成 X（PUT 覆寫）、刪除某 ID（DELETE）——重複做結果相同。
- 非冪等：
POST 建立、餘額 +100、計數器遞增——重複做會多算。 - 設計時盡量把操作改成「設定到目標狀態」而非「相對變更」。
不冪等的操作怎麼補救
- 去重鍵（idempotency key）：客戶端為每次操作帶一個唯一 ID；伺服器記下已處理過的 ID，重送就直接回上次結果、不重做。
- 訊息場景：用訊息 ID 去重，或把「處理 + 標記已處理」放進同一交易。
- 把狀態存資料庫，收到重複請求時先查「這個 ID 做過了嗎」。
🔑 Takeaways
- 重試 + at-least-once ⇒ 必然重複；冪等是安全重試的前提，不是可選項。
- 能設計成天生冪等（設定目標狀態）就最好；不能就加去重鍵 / 訊息 ID。
- 別硬追 exactly-once——at-least-once + 冪等消費者是更務實的組合。
No notes yet — jot your takeaways or Q&A here.