Skip to main content
KISS C#版YAGNI C#版SoC C#版ADR C#版HC/LC C#版DRY C#版Refactoring C#版テスト容易な設計 C#版TDD C#版エラーモデリング C#版レイヤー C#版MVC C#版依存関係ルール C#版DIP C#版DI C#版Is-a/Has-a C#版SOLID C#版GoF C#版Observer C#版CQS C#版状態機械 C#版不変条件 C#版Entity/VO C#版DDD C#版集約と境界 C#版ドメインイベント C#版モジュラーモノリス C#版ヘキサゴナル C#版クリーンアーキ C#版ACL C#版API Contract CSSemVer C#版DbC C#版冪等性 C#版CAPの肌感覚 C#版Outbox C#版Saga C#版CQRS C#版ES C#版境界づけられたコンテキスト C#版

第01章：まず「Outboxって何のため？」を超ざっくり掴む 😺📦

今日のゴール 🎯✨​

この章のゴールはたったこれだけです👇 **「DBの更新」と「外への通知（メール・キュー・HTTPなど）」がズレて事故るのを防ぐために、Outboxを使うんだな〜**ってイメージを持つこと💡

まず最初に：よくある事故ストーリー 😱📩​

事故A：注文は保存されたのに、メールが飛ばない 🛒✅→📧❌​

たとえばネットショップで…

  1. 注文をDBに保存する（成功）✅
  2. 「注文ありがとうメール」を送る（失敗）❌（ネットワーク不調・メールサービス落ち・タイムアウト…）

結果：

  • お客さん「買ったのにメール来ない…不安😢」
  • 運営「DB見たら注文ある！でもメール送れてない！どこまで処理したっけ？😵‍💫」

事故B：メールは飛んだのに、注文が保存されてない 📧✅→🛒❌​

逆もあります…（これ、もっと怖い😇） 「注文確認メールが来たのに、注文が存在しない」みたいな世界線が爆誕します💥

なんでズレるの？ざっくり理由 🌍🌀​

Dual Write Failure

ポイントはここ👇 **DBに書くのと、外の世界に通知するのは“別の場所・別の仕組み”**だからです。

  • DB更新：同じDBの中ならトランザクションで守れる🔒
  • 外への送信：ネットワーク越し・別サービス・別サーバー…失敗しうる🌩️

この「別々のものを、両方まとめて成功させたい」問題を、一般に Dual Write（2重書き込み）問題 と呼びます💣 たとえば「DB更新」と「メッセージングシステムへの書き込み」を“原子的に（全部成功 or 全部失敗で）”やりたいのに、それが難しくて不整合が起きる…という説明がされています。(Confluent)

Outboxって何？ひとことで 🍙📦​

**Outboxは「あとで送るための“発送待ち箱”」**です📮✨

「今すぐ外に送る」のをやめて、いったんこうします👇

  • ① まず DBの中に「送る予定のメッセージ」を保存する（Outboxテーブルなど）🧾
  • ② あとで別の仕組み（配送係）がそれを読んで送る🚚📩

そして超大事なのがここ👑 業務データの更新（例：注文テーブル）と、Outboxへの記録を“同じDBトランザクション”で一緒にやることです🔒✨ これにより「注文はあるのに通知がない」みたいなズレを起こしにくくします🛡️ この考え方は「Transactional Outbox（トランザクション送信トレイ）」として、信頼できるメッセージングや確実な配信を支える方法として説明されています。(Microsoft Learn)

図でつかむ：Outboxなし vs Outboxあり 🧠🖼️​

Outboxなし（事故りやすい）😵‍💫​

[アプリ] 
  ├─ DBに保存 ✅
  └─ 外へ送信 ❌（落ちることがある）
          ↓
      ズレ発生 😱

Outboxあり（ズレを減らす）😺📦​

[アプリ]
  └─ (同一トランザクション)
       ├─ DBに保存 ✅
       └─ Outboxに「送るもの」を保存 ✅
               ↓（あとで）
         [配送係] がOutboxを読んで外へ送信 🚚📩

Outboxがくれる嬉しさ 3つ 🌟🌟🌟​

1) 「DB更新は成功したのに通知失敗」の混乱が減る 🧹✨​

通知が失敗しても、Outboxに“送るべき記録”が残るので、あとでリトライできる土台ができます🔁

2) “どこまで処理した？”が追える 🔍​

Outboxが「発送待ちリスト」になるので、未送信が見える化👀📦 （第22章の観測にもつながるやつ！）

3) 現実的な信頼性に寄せられる 🤝​

分散システムでは「外への送信」は失敗が前提になりがちなので、パターンとして整理しておくのが強いです💪 （このへんは後半で「At-least-once」「冪等性」につながるよ🧷✨）

ここでミニ演習 📝💡（手を動かさなくてOK！）​

あなたが作ったことがありそうな機能を1つ思い浮かべてください👇（例：会員登録、注文作成、予約確定…）

そして、次の3つを埋めてみてね☺️✍️

  1. DBに保存するもの：例）Ordersに1レコード
  2. 外へ通知したいこと：例）「注文確定しました」メール
  3. 通知が失敗したら困ること：例）問い合わせ増える、二重注文の疑い、手動対応地獄😇

これが埋まったら、もうOutboxの必要性の入口に立ててます🙆‍♀️✨

よくある勘違いを先につぶす 🙅‍♀️💥​

  • 「Outboxって、送信を絶対成功させる魔法？」 → ちがうよ〜！Outboxは「ズレを減らして、失敗しても立て直せる形」にする仕組み📦🛠️
  • 「Outboxを書いたら即送信しなくていいの？」 → 送信はする！でも役割を分けるのが大事。 「書く人」と「送る人」を分けるイメージ👥🚚

この章のまとめ 🍀📌​

  • DB更新と外部送信を別々にやると、失敗でズレて事故る😱
  • それが Dual Write 問題で、分散・外部連携では起こりやすい💣(Confluent)
  • Outboxは「発送待ち箱」📦
  • DB更新とOutbox記録を同じトランザクションで行い、あとで配送係が送る🚚📩(Microsoft Learn)

次の章では、「なんでそんなにズレるのか」をもうちょい具体的な失敗パターンで見ていきます😵‍💫🧨