20250302メモ

単一障害点 ... そこが動かなくなるだけで、システム全体が死んでしまうような箇所のこと。マイクロサービスと非同期メッセーングを使う場合、メッセージブローカーが動かなくなるとやばい

二相コミット ... 分散DBにおいて、すべてのDBのコミット可能性を確認してからコミットすること

Transactional Outboxパターンで、メッセージキューとなっているテーブルからメッセージブローカーにメッセージをpublishする方法は２通り

1. テーブルをポーリングしてヒットしたものを送る方法

2. トランザクションログをテーリングする方法

1はひたすらSELECT文を投げ続けるイメージでシンプルだが無駄が多く負荷になる可能性がある

2は メッセージのINSERTがcommitされたことをフックするイメージなので 1と比べて無駄がないが、高度なしくみを作る必要がある

弊社はどっちを採用してるんだろう・・・？

他サービスとの連携は非同期メッセージングで全部済ませられればいいが、現実そうはいかないこともある。

非同期メッセージングを使えないからといって、同期にしなければいけないということはなくて、同期通信を減らすことはできる。

自サービスのみでリクエストを処理できるようにするには、例えば、他サービスにマスターデータを持ち、自サービスにレプリカを持つという方法もある。（ex. Read Model）

この場合、リクエストを処理したらレスポンスを返したあと、他サービスとメッセージを交換して処理を進める。

仮に他サービスが落ちていても、メッセージブローカーは落ちているサービスが復活したタイミングでキューを配信できるから、ユーザーに対する影響を抑えることができる。