複数のサービスや DB にまたがる処理の整合性を、どう保ちますか

なぜ 1 つのトランザクションにできないか

1 つの DB の中なら、トランザクションで「全部成功か、全部無かったことか」にできます。しかし注文のサービスと決済のサービスが別の DB を持つと、片方だけ成功して片方が失敗することが起きます。複数の DB をまとめて確定させる仕組み (2 相コミット) もありますが、すべての参加者が対応している必要があり、1 つが止まると全体が待たされるので、Web のサービス間ではあまり使いません。

手順に分け、失敗したら打ち消す

注文を、在庫の確保、決済、配送の手配、の手順に分けます。それぞれに「打ち消す処理」を用意し、途中で失敗したら、済んだ手順を逆の順で打ち消します。この進め方はサーガと呼ばれます。動きを小さく書くと次の通りです。

const steps = [
  {
    name: "在庫の確保",
    run: () => console.log("在庫を確保"),
    undo: () => console.log("在庫を戻す"),
  },
  {
    name: "決済",
    run: () => {
      throw new Error("カードが通らない");
    },
    undo: () => console.log("決済を取り消す"),
  },
  {
    name: "配送の手配",
    run: () => console.log("配送を手配"),
    undo: () => console.log("配送を取り消す"),
  },
];

function runSaga(steps) {
  const done = [];
  for (const step of steps) {
    try {
      step.run();
      done.push(step);
    } catch (err) {
      console.log(step.name + "で失敗 " + err.message);
      for (const d of done.reverse()) {
        d.undo();
      }
      return "取り消して終了";
    }
  }
  return "すべて成功";
}

console.log(runSaga(steps));

在庫を確保
決済で失敗 カードが通らない
在庫を戻す
取り消して終了

打ち消しは「無かったこと」ではなく「逆の操作」です。支払いなら返金、メールなら「取り消しました」のお知らせになります。送ったメールは消せないので、取り消しにくい手順ほど後ろに置きます。注文には「確定待ち」のような途中の状態を持たせ、利用者にもそう見せます。

DB の更新と知らせをずらさない

「注文を DB に保存し、それからキューに『注文ができた』と送る」と書くと、保存の直後にサーバーが落ちたとき、知らせが永遠に送られません。逆の順だと、知らせだけ送られて注文が無い、が起きます。

そこで、知らせを送る代わりに、同じ DB の「送る予定の知らせ」の表に、注文と同じトランザクションで書きます。別の働き手がその表を読んでキューに送り、送れたら済みの印を付けます。この形はアウトボックスと呼ばれます。働き手は送ったあと印を付ける前に落ちることがあるので、同じ知らせが 2 回送られることはあります。だから受け取る側は、知らせの id を処理済みとして記録し、2 回目は何もしないようにします。決済の API の二重の送信と同じ考えです。

照らし合わせで拾う

打ち消しそのものが失敗する、知らせが何度送っても届かない、ということも起きます。何度か試して届かない知らせは別の置き場 (デッドレターキュー) に移して人が見ます。さらに、注文と決済の記録を定期的に照らし合わせ、片方にしか無い物を見つけて直す処理を用意します。

トレードオフ

この作りは、手順ごとの打ち消し、途中の状態、照らし合わせと、1 つの DB で済む場合よりずっと手間がかかります。「少しの間、在庫と注文の数がずれて見える」ことも受け入れる必要があり、どこまで許すかを事業側と決めます。分ける理由が弱いなら、同じ DB に置いて 1 つのトランザクションで済ませるほうが、確実で安く済みます。

話す例は架空の例で構いません。「ポイントの付与を別のサービスに分けたら、付与の漏れが出たので、注文と同じトランザクションで送る予定の知らせを書き、毎晩照らし合わせるようにした」のように話せると伝わります。