マイクロサービスアーキテクチャでの通知：アプリケーションロジックとデータベーストリガー
環境
私たちのグループは、より大きな教育機関向けに複数のアプリを作成し、維持する責任があります。モノリスを再利用可能なマイクロサービスに分割する処理を行っています（フレイ！）。通知（主に電子メール通知）に取り掛かると、行き詰まってしまいました。私たちのユーザーは複数のアプリケーションを使用し、各サービスには他のユーザーへの通知を発する数十のトリガーポイントがある場合があります。すべてのマイクロサービスが独自の通知を処理する必要があるか、またはすべての通知がサービスに属し、データベーストリガーに依存する必要があるという考え方を採用していますか？
これは私たちが本当に、間違いを犯すわけにはいかないので、記事またはおそらくいくつかの経験に関するアドバイスを探しています。
サービス中の通知に関する議論
マイクロサービスは自己完結型である必要があります。それぞれが独自の状態、独自のモデルを担当し、機能するために別のサービスに依存しないようにする必要があります。通知は、多くのサービスにとって不可欠な機能です。新しいチャットをチェックするために毎回開く必要がある場合、チャットサービスはどのように役立ちますか？アクションでは、マイクロサービスは通知を発する必要があります-直接か、またはいくつかのメール配信サービスでエンキューするかによって。これは、緩和とさらなる開発にも役立ちます。サービスを反復している間、開発者は、アプリケーションの状態の変化に応じて送信される通知を常に認識しています。
データベーストリガーの場合
送信される通知の量を考慮して、一元化することをお勧めします。通知の更新、追加、削除はすべて1か所で行う必要があります。さらに、アクション（または流動的なアクション）から通知を送信することは危険です。アクションが実行された後、DML操作が失敗する可能性があるためです。これにより、ユーザーは真実の情報源、つまりデータベースと同期していない通知を受け取ります。通知サービスがデータベース内のトリガーのみに依存するようにすることで、サービスのカプセル化も維持されます。通知サービスは、どのサービスがどのモデルを更新したかを気にせず、モデルdidが実際に更新されたことだけを考慮します。別のリスクは、複数のアプリケーションが同じテーブルで動作していることです（これは貧弱なアーキテクチャのように見えるかもしれませんが、管理アプリとユーザーアプリがあるかもしれません）。テーブルを更新する複数のサービスがある場合、競合するエントリを持つユーザーに複数の通知が送信される可能性があります。集中化することで、1つの通知のみが送信されるようにすることができます（おそらく、1つの間隔で送信される通知の数を抑制し、最後の変更のみを通知することにより）。
質問
私たちは、それぞれが数十の通知を持っているかなりの数のマイクロサービスを担当しています。私たちのチームは非常に急速に成長しており、私が恐れているのは、各地に通知が届くことです。開発者が誤ってコードを切り替えて、これが貧弱なユーザーに大量の通知をトリガーすることに気付かない可能性があります。私にとって重要なのは、組織全体の一貫性です。
上記で説明した2つのアーキテクチャ間のトレードオフ、つまりアプリケーションロジックからの通知またはデータベーストリガーからの通知についてのアドバイスを期待しています。
本当にありがとうございました！
3番目のオプション：通知を独自のマイクロサービスにします。各マイクロサービスは、通知マイクロサービスとの通信に独自の内部ルールを利用できます。通知マイクロサービスは、プッシュする前にチェックする必要があるさまざまな検証ルールのいずれかが与えられた場合、プッシュ通知用の独自の内部ルールセットの実行に集中できます。
さて、あなたのマイクロサービスは基本的にサービスレイヤーの一部ですよね？クライアントはそのサービス層のイベントエンドポイントにサブスクライブします。それは変わりません。したがって、唯一の真の質問は、「どこからイベントが発生するのか？」
データベーストリガーは、これには不適切なツールです。データベーストリガーには別の目的があります。モノリシックアーキテクチャを削除する場合は、イベントの発生をそこに配置します逆の効果があります
代わりに、単一のマイクロサービスにイベントを集中化するか、各マイクロサービスに独自の通知を処理させます。
これは「単一の真実の源」についてではありません。すべてのマイクロサービスは、取得された時点の状態でデータベースからデータを取得します。イベントはその点で特別ではありません。