I/F設計ガイドライン: 受信ワークテーブルを共有する方法

Author: ma91n

documents/forIF/if_guidelines.md

@@ -187,6 +187,48 @@ REFRESH MATERIALIZED VIEW CONCURRENTLY schema_name.view_name;
   - 万が一のセキュリティ事故時の影響度範囲が限定しにくい（セキュリティホールにならないように、統制すべき対象が増える）ため。また、権限設定の設定ミスや、脆弱性を突かれた際の影響範囲が、単一システム内に留まらなくなる
   - 接続システム側が予期しないクエリを実行することで、接続先DBに対して高負荷を与えてしまうことが原理上に存在するため
 
+## 受信ワークテーブル共有
+
+DB共有の一種で、直接本番テーブルを参照・更新させるのではなく、データ連携専用の「受信ワークテーブル」を介在させ、処理のトリガーにWeb APIなど用いる「プッシュ型」の連携パターンが考えられる。
+
+ファイル連携における「送信ファイル」の代わりに、送信側が受信側の「受信テーブル」に対してデータを直接書き込む点が特徴的である。
+
+```mermaid
+%%{init: {'sequence': {'mirrorActors': false}}}%%
+sequenceDiagram
+  participant Sender as 送信側システム
+  participant IFTbl as 受信側 I/Fテーブル
+  participant ReceiverAPI as 受信側 Web API
+  participant ReceiverDB as 受信側 本番テーブル
+
+  Sender->>IFTbl: INSERT / COPY
+
+  Sender->>ReceiverAPI: POST /api/notify_import<br/>{batchId: "123"}
+  activate ReceiverAPI
+
+  ReceiverAPI->>IFTbl: SELECT (バリデーションも実施)
+  ReceiverAPI->>ReceiverDB: INSERT / UPDATE
+  ReceiverAPI-->>Sender: 200 OK (完了または受付)
+  deactivate ReceiverAPI
+```
+
+主な評価観点を次にまとめる。
+
+| 観点         | 評価         | 説明                                                                                                                                                                               |
+| :----------- | :----------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 性能         | ✅️メリット   | I/Fファイルの生成・転送・パース処理が不要なため、オーバーヘッドが少なく、より高速に動作する                                                                                        |
+| 保守性       | ❌️制約       | 受信テーブルのスキーマは送信側の都合で決定されることが多く、受信側は常に最新のスキーマに追従する必要がある（変更頻度が高いI/Fには不向き）                                          |
+| セキュリティ | ❌️デメリット | 送信側システムに対して、受信側DBへの「書き込み権限」を付与する必要がある。インバウンド通信を許可する必要があり、ネットワーク設計やセキュリティグループの設定が複雑になりがちである |
+| 安定性       | ❌️デメリット | 送信側が直接DBリソース（コネクション、I/O等）を消費するため、受信側のDB性能に影響を与えるリスクがある                                                                              |
+
+推奨は以下の通り。
+
+- 原則としては採用しない。ファイル連携の方が、責任分界点やセキュリティの観点で優れているため
+- ただし、以下の条件をすべて満たす場合に限り、採用を検討する
+  - ファイル連携基盤が存在し、ハブが「受信テーブルへの書き込みと通知」をマネージドに代行してくれる機能を持つ場合
+  - ファイル生成・パースのオーバーヘッドさえも削減したいほど、大量データかつ厳しいレイテンシ要件（秒レベル）がある
+  - I/Fのスキーマ変更がほとんど発生しない、枯れたデータ連携である
+
 # RPC呼び出し
 
 RPCによるデータ連携は、現代的な解釈ではWeb APIを用いた連携に該当すると考えられる。さらにシステム間のデータ交換の文脈ではWebSocketやServer Sent Eventを用いたイベント駆動ではなく、同期的なリクエスト・レスポンスの利用が一般的である。RPC呼び出しは、リアルタイムにデータ連携できるという即時性のメリットと、同期処理に起因してシステム間の結合度が高まるというデメリットを、業務要件やシステム特性に照らしてどう評価するかが設計ポイントである。