2 つのシステムに書く — 片方だけ成功した状態を、先に設計しておく

What — 1 つのトランザクションにならない相手

自社の DB の中なら、2 つの書き込みを1 つのトランザクションにできます。両方成功するか、両方なかったことになるかのどちらかです（トランザクションと分離レベル）。

外部のサービスは、そうはいきません。決済、メール送信、在庫の外部システム、会計ソフト。相手の DB と自分の DB を、同じトランザクションで包む方法はありません。どちらかを先に書き、もう片方を後に書くしかない。その間で止まれば、片方だけが残ります。

① 課金する（外部）   ✓
 ── ここで止まる ──
② 契約を有効にする    ✗

残る状態:
払った。でも使えない

片方だけ成功した状態を、名前のある状態にする

3 つ目のやり方の要点は、途中の状態に名前を付けて、自社の DB に残すことです。

「外部が先」「自社が先」の失敗は、途中の状態がどこにも記録されないことでした。記録があれば、止まっても自社の側から見つけて、続きをやれます。

そのために、外部に頼むときは冪等キーを渡します（冪等性）。止まったあとに同じキーでもう一度頼んでも二重にならず、そのキーで結果を照会できます。

取り消しと、突き合わせ

途中で止まったものを確定させる方法は、2 つあります。

取り消し（補償）: 片方が成功し、もう片方が失敗したと確定したら、成功したほうを取り消す操作を別に行います。課金したのに契約を作れないなら、返金する。ロールバックと違い、取り消しも 1 つの新しい操作なので、これ自体も失敗しうるし、記録が要ります。

突き合わせ: 定期的に、自社の記録と外部の記録を並べて、ずれを探します。「決済サービスでは成功、自社では課金中のまま 10 分」「自社では有効、決済サービスには記録が無い」。どんな設計でも漏れは起きうるので、最後の網として置きます。

Why — なぜ「順番を工夫する」では直らないのか

どの順番にも、止まる場所がある

冒頭のチームは、順番を逆にすれば直ると考えました。しかし、2 つの書き込みの間は必ず存在します。サーバーの入れ替え、タイムアウト、プロセスの強制終了、ネットワークの切断。どれも、どの行の間でも起きます。

順番で選べるのは、止まったときにどちらへ倒れるかだけです。

• 払ったのに使えない（利用者が損をする）
• 払わずに使える（自社が損をする）

どちらを許すかは事業の判断で、多くの場合は利用者に損をさせない側に倒します。ただし、どちらに倒しても、倒れたことに気づけなければ意味がありません。

外部の応答が来ないのは「失敗」ではない

冒頭のアプリは、課金の応答を受け取る前に止まりました。仮に止まらなくても、応答がタイムアウトしたら同じことが起きます。リトライとタイムアウトで見たとおり、タイムアウトは「失敗した」ではなく「分からない」です。

分からないのに「失敗しました」と表示すると、利用者はもう一度押し、2 回目の課金が走ります。分からない状態を「課金中」として持ち、確かめてから答えるのが正しい扱いです。

外部のほうが「正」であることが多い

お金が動く記録、送ったメールの記録。多くの場合、外部のサービスの記録のほうが事実です。自社の DB は、それを写したものにすぎません。

だから、ずれたときは外部に合わせて自社を直すのが基本です。外部に照会できる手段（冪等キー、取引 ID、Webhook の再送）を、設計の最初から確保しておきます。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。