"Idempotency"
- 11.8 API 層冪等設計
idempotency key 誰生成、存多久、replay 回什麼、衝突怎麼回 — 對外冪等契約的條款設計與無標準現況
- Idempotency key 標準化之爭：標準統一得了揭露的形狀、統一不了業務綁定的值
整合或自建冪等機制時各家條款的實質差異：replay 回首次快照還是最新狀態、保存期是否明文、同 key 並發怎麼處理
- DynamoDB Transaction 與 Conditional Write：跨 item 原子性、optimistic locking 與 idempotency
DynamoDB 的寫原子性不是免費 ACID；本文展開 TransactWriteItems 跨 item 原子性、ConditionExpression 條件寫、version-based optimistic locking、ClientRequestToken idempotency，以及 transaction 2x 成本邊界與何時用單 item conditional write 取代 transaction
- 11.C38 Stripe 冪等設計哲學：retry 是 client-server 協作
三種失敗點的 replay 行為分析、client 端 backoff + jitter 責任；冪等只做 server 半邊會放大故障
- 11.C39 Stripe 冪等鍵契約條款：24h 保存、500 也重放
可承諾的冪等契約細節：重放的是該次請求的結局而非成功結果、同 key 不同參數即錯
- 11.C40 IETF Idempotency-Key draft：標準化停在 expired
de facto 先於 de jure 的具體例：業界事實標準先行、IETF 標準化跟進後停滯；引用必標 expired 狀態
- 11.C41 PayPal-Request-Id：同語意、不同契約的冪等實作
跟 Stripe 的三點對照：header 命名、replay 語意（最新狀態 vs 首次結局）、契約精確度
- 11.C45 Twilio 2013 計費事故：無冪等防線的重複扣款（反例）
反例：內部 retry 迴圈缺冪等閘門等效於無限重放、fail-safe 是金流 side effect 的斷路器