#idempotency

読んでまず思ったのは、これは「失敗した通信をもう一回やればいい」という単純な話では全然ない、ということだった。iPhone側ではただタイムアウトしたように見えても、サーバー側ではもう処理が走っているかもしれない。しかも agent や tool を呼ぶ話になると、その一回の重複がそのまま課金、在庫確保、メッセージ送信の二重実行につながる。ここを雑に扱うと、あとで帳尻を合わせるのがかなり苦しいはずだ。 特に腑に落ちたのは、「exactly once」をあれこれの基盤に期待しすぎない、という姿勢だった。Kafka には Kafka の中での保証がある。でも iPhone、HTTP、agent、MCP、DB、外部APIまでまたぐと、その保証は途中で切れる。記事が言っている effectively-once という考え方は、きれいではないけれど現実的だと思う。要するに、何かが再試行されても同じ operationId で拾い直せるようにしておく。全部を一発で正確にするのではなく、重複しても最後は1つに収束するように設計する。 この手の話で地味に重要なのに、軽く見落とされがちなのが「operat