DLR、遅延、フェイルオーバー：プロダクトと財務の一つの真実

プロダクトはコンバージョンを求める。財務は予測可能なデビットを求める。運用はダッシュボード・webhook・請求書で同じ意味の状態語を求める。DLR・遅延・failover が三つの口径に分かれると、事故のたびに語彙争いとなり、議論のあいだに前払いが燃える。

IOSOR は white-label の前払いメッセージングを、チャネル横断の 一つの状態辞書 で運用する。クライアント向けエラーは安全で、外来ブランド名を買い手に流さない。カタログは live のときだけ能力を約束する。in setup は live ではない。月次プラットフォーム利用が USD 1,000+ に近づくと、終端状態のエクスポート、コリドー別レイテンシ帯、failover 試行ごとのデビットが、より密な商用レビューの材料になる。証拠が先、拡大は後。

経営向けの単一の真実表

一度のエクスポートで三行すべてに答えられなければ、まだ一つの真実はない。経営層が月末を三枚の表から組み立てるべきではない。層ごとの共有成果物は、語彙争いを始める前に止める最も安い方法である。レビューは同じファイルを開き、後付けの画面キャプチャ三枚ではない。

監査に耐える DLR 連携

• 受信イベントは署名または認証済み
• 冪等なコンシューマーと安定した重複排除キー
• 送信 → 状態 → 台帳の相関
• 製品内で直近配送を検査できること

未署名の webhook と非冪等なコンシューマーは、再試行を重複チケットと重複デビットに変える。SMS到達性の運用ガイド と 未達・拒否・期限切れステータス を参照。カタログが live なのに DLR を台帳へ相関できない約束は、財務が守れない。当番は一つの相関 ID で送信から終端状態、デビット行まで追えるべきである。webhook の undelivered / rejected / expired が請求書と違う意味なら、連携は監査に耐えない。

レイテンシ帯域であり、見栄えの平均ではない

コリドーごとに accepted → submitted → delivered を追う。OTP のコンバージョンは地理で形が変わる。世界平均は壊れた市場を隠す。遅延が悪化したら、再試行・failover・停止を指名された責任者で決める。希望ではない。週次で p95/p99 を切り、弱いコリドーが世界平均の陰に隠れないようにする。持ち主のいない遅延は、未払いの再試行ループになり、OTP が届く前に前払いが燃える。

前払い規律のある failover

Failover は利用者を救う——あるいは財布を燃やす。

1. メッセージごとの自動試行に上限を付ける。
2. 利用者の再送とシステムの failover を分ける。
3. in setup のカタログ項目へ failover しない。
4. 試行ごとのデビット規則を文書化する。

本番 failover チェーンの mock 経路は安全網ではない。音声/SMS の退避は 音声アラートとOTPフォールバック と組む。プロダクトと財務は一つのメッセージの全試行をエクスポートし、相関 ID を揃える。再試行に上限を付けてから、死んだコリドー上の高いループに failover をしない。

危険信号

• 画面で delivered と sent を同義に使う
• failover 試行が財務から見えない
• 本番 failover チェーンに mock 経路がある
• webhook と請求書で状態語が違う
• 証拠が画面キャプチャだけ
• カタログが in setup なのに failover を約束する
• クライアント向けエラーに外来ブランド名が出る

IOSORで始める

廊下を一本、メッセージ種別を一つに絞る。先週の終端 DLR を製品と財務の共有辞書へ出し、同じ correlation ID を検証、failover、ウォレット減算まで通す。経路切替を模擬し、利用者が見た結果と台帳の減算を数える。財務が再試行や failover 減算を持っているなら、画面の Delivered を直す。

IOSORの要点

製品と財務は同じ correlation ID で一つの DLR、一つの遅延時計、一つの failover 結果を読む。利用者に見える状態のない減算は嘘だ。

する：対照表を出し、書き出す。しない：財務が復元できない状態を製品が作ること、緑バッジの後ろに failover 減算を隠すこと。