注目★★★★★Hacker News
Webhook の落とし穴──3 回目で気づく、通知は複製の道具ではない
30秒で把握
- 1開発者が 3 度同じ webhook 処理システムを再構築、毎回署名検証・重複排除・夜間修正が必須に
- 2Webhook は通知用途で設計されたが、データ複製に流用され、完全性・順序保証の欠落が隠れコスト化
- 3Stripe API など順序付きログの公開で局所最適からの脱出開始、業界の設計思想転換が進行中
要約
エンジニアが 3 社で同じシステムを再構築し続ける現象の根底にある問題は、webhook が通知（notification）であって、完全で順序付きのデータセット転送に適していないということだ。webhook を利用するたびに署名検証・重複排除・バッファリング・ブートストラップ・夜間の差分修正クローンなど多層の補正が必須になるが、これはプロバイダーの履歴ログが存在するのに、それを HTTP POST に細切れにして配信し、消費者側で再組立させる非効率な設計による。Webhooks は 2007 年に副作用を引き起こす目的で生まれた優れた仕組みだが、15 年かけてデータ複製という本来の役割外の用途に拡大し、その結果いまや Svix・Hookdeck・AWS EventBridge・Fivetran などの整備産業が谷底で栄えている。Stripe の 30 日イベントログ API のような提案も出始めているが、業界はこの局所最適から抜け出し、根本的に別の設計（例：真の change data capture）への移行を検討すべき時期にある。
あなたへの影響
多くの開発チームが webhook ベースの連携を当たり前と考えているが、本記事は長期運用で発生する不可視なズレ（顧客削除が届かない、到着順序が保証されない）が必然的に夜間バッチやクローン修正を招く宿命を指摘している。
推奨：新規統合時は Webhook の全体的な信頼性コスト（署名検証・dedup・cron）を予算に含め、または API で順序付きログを公開するプロバイダーへの移行を検討する価値がある。