複数アプリケーション + 単体DBの運用パターン

前提

マイクロサービスのような言い方があるのかもしれないけど、マイクロサービスとは何かを明確に言葉に出来ないので分かっている範囲の言葉を使う。
複数アプリケーションが単体のDBの情報を利用しなければいけない場合に現状試しているパターンを列挙する。

図の例で使う言葉の定義

単体DB（とそれを操作するアプリケーション）

言葉	定義
利用者DB	複数アプリケーションを利用する者（利用者）のアイデンティティ（識別IDや名称）が記録されるDB。タイトルや上記前提に記載の単体のDBである。
利用者アプリケーション	利用者DBを操作などを行うアプリケーション。

複数アプリケーション（とそのリソースやイベントを記録するDB）

言葉	定義
予約DB	上記の利用者の予約を記録するDB。
予約アプリケーション	予約DBの操作などを行うアプリケーション。
チャットDB	上記の利用者のチャットを記録するDB。
チャットアプリケーション	チャットDBの操作などを行うアプリケーション。

パターン

APIパターン

複数アプリケーションが利用者の情報が必要なときに、利用者アプリケーションに用意されたAPIにリクエストを送る。
予約DBは利用者の識別ID以外の情報には関与しない。
デメリットは利用者の情報と予約アプリケーションの情報を組み合わせた情報を取得する際に、複数回APIリクエストをしなければいけない事がある。その場合は、下記のパターンを検討する。

DB複製パターン

既に利用者DBがある場合は事前に、利用者DBのテーブルの利用者情報を複製しておく。
以降は、利用者アプリケーションに利用者情報の変更（新規登録）のイベントが起こる場合に、その変更イベントと変更内容を複数のアプリケーションのAPIに通知する。
通知を受け取ったらその内容に応じて、自身のDBのテーブルに記録する。