おめでとう、ミューテックスを発見したね。本当に分散システムなのか、それとも中央データベースを持ったサービスの集まりなのか？

UDFの最後のポイントがよくわからない。異なるシステム間で状態を原子的に更新する必要があるのか、そうでないのか。将来的にランダムなタイミングで2つ目を更新するためにシステムに行を追加するのは、キューにジョブを入れるのとあまり変わらない気がする。

私の理解では、ワークフローの進行単位とデータベースのコミット単位を1対1で合わせているってことだね。つまり、ワークフローの各ステップがデータベースのコミット単位になる。だから、アウトボックスパターンが簡素化されるんだ。でもその代わり、データベース自体がワークフローに密接に結びつくから、後で分離するのがアーキテクチャ的に難しくなる。とはいえ、実際にはデータベースを分離する必要はほとんどないんだけどね。ほとんどのサービスでは、メッセージブローカーやワークフローエンジンを入れ替えることはあるけど、データベースはほぼそのままだから。この理解が合ってるかは自信ないな。

クライアントのメール送信のために、外部サービスとのインタラクションに対してトランザクションの原子性を利用したフェイルセーフアプローチを採用してる。正式なキューを使っても同じように動作して、今日の保証を得ることができるけど、当時はそんなインフラにお金をかけるほどの規模じゃなかったからね。内部では、保留状態から計算された状態にデータを変換するために複雑なロジックを実行するジョブがあって、DBの原子性に依存してデータが成功裏に移行することを保証してる。そのタスクはすごく頑丈なんだけど、二次的な永続ストレージが関与する場合、トランザクションの保証は何らかの形で妥協しなきゃいけない。メール送信の例では、クライアントがすべての通知を受け取ることを保証する方が、通知が正確に一度だけ送信されることを保証するより重要だと思ってる。だから、メール送信が成功したことを確認してから、そのメッセージを保留リストから削除するトランザクションを閉じるってメカニズムを使ってる。太陽フレアとかの影響で潜在的な損失が出る可能性は常にあるけど、こういうシステムを設計する際の鍵は、システムがどう失敗するかを理解し、その結果を受け入れて、できるだけサイクルやロジックの距離を縮めることだと思う。ロジックは、不可逆的なアクションが起こる前にできるだけ準備作業をして、不可逆的なアクションは好みに応じて順序を決めて、安全かつ迅速に安価に処理するべきだね。

うちには、メインアプリケーションのデータベースにあるインハウスのpubsubソリューションがあって、記事に書いてある通りの感じだよ。そして、それが許す原子性は本当に素晴らしい！

数年前、ある面接でこの点で退席したことがあるんだ。技術的な質問の一つが「データベースとメッセージキューがあったら、どうやって両方を更新するか、またはどちらも更新しないか（つまり、トランザクショナルに）」ってやつだった。数分考えた後、「無理だし、君も無理だよ」と返したんだ。それから、レプリケート状態マシンや書き込み先行ログ、イベントソーシング（その時の呼び方は何でもいいけど）を使って、最終的な整合性に頼るのが唯一の実用的な解決策だって提案した。そしたら、彼がアウトボックスパターンについて聞いたから、説明してもらった。確かに、この記事に似てるなと思ったよ。データベースDとメッセージキューQをトランザクションで扱う秘訣は、Dを二つの部分（ステートとアウトボックス）に分けて、代わりにそれら（S,O）を通じてトランザクションを行い、DとQの間にトランザクションがあるふりをすることなんだ。