マルチテナントのマイクロサービス設計

現在、モノリシックアプリケーションをマイクロサービスアーキテクチャに移行しています。いくつかの規制要件により、異なる国のクライアントのデータを個別の（国固有の）データベースに保管する必要があります。すなわち、米国の顧客のための米国db、英国の顧客のための英国db ...

私たちが検討している次の設計は次のとおりです。

オプション1：必要に応じてN回までスケーリングできる、休止状態のマルチテナントサポートを備えたマルチテナントアプリケーション（kubernetesポッドを考えてください）。このアプリケーションの単一インスタンスは、すべてのデータベースに接続できます。

オプション2：国のデータベースごとに1つのマイクロサービスインスタンスを展開します。APIゲートウェイの前にトラフィックをルーティングする

このタイプのシステムを設計する場合、どのような選択肢がありますか？

オプション2は悪いものではないと思いますが、必要ではないかもしれません。マイクロサービスは、複数のアプリケーションのニーズに対応するためのものです。

ここでの大きな要因は、2つのスキーマに違いがあるかどうか、そして将来あるかどうかです。

通常、リポジトリにインターフェイスを使用する必要はないと思います。ただし、この場合は努力する価値があるかもしれません。リポジトリファクトリは重要です。

オプション1の私の問題は、あまりにも具体的であるということです。説明したセットアップから、それぞれが独自のDBを指す2つの別々のインスタンスに簡単に移動できるはずです。アプリケーションは、データを取得する場所を気にするべきではありません。

スキーマは2つの異なるデータベースで違いはありませんが、1つのリポジトリで両方を簡単に処理できます。アプリケーションは違いを認識しません。

public class MyEntityRepository : ISavesMyEntity, IGetsMyEntity
{
    public MyEntityRepository(string connectionString)
    {
       _connectionString = connectionString;
    }
}

public class MyEntitySaverFactory
{
    public ISavesMyEntity GetSaver(User user)
    {
        if (user.IsUK)
            return new MyEntityRepository(Config.Get("UKConnString"));
        if (user.IsUS)
            return new MyEntityRepository(Config.Get("USConnString"));
        throw new NotImplementedException();
    }
}

//USE
ISavesMyEntity saver = factory.GetSaver(currentUser);
saver.Save(myEntityInstance);

DBスキーマが米国と英国で異なる場合、機能を2つの完全に異なるリポジトリに分割します。あなたがしなければならないのはあなたの工場を変えるだけなので、これは簡単でしょう。

2番目のオプションを選択すると、開発と展開の摩擦が少なくなります。

これにより、全世界で少なくとも1つではなく、リージョンごとに1つ（または少なくとも1つ）のインスタンスにアプリを配布したため、スケーラビリティと可用性が向上し、ゼロダウンタイムの展開オプションが改善されます。

要件が変更されると、地域固有のビジネスロジックが増え、データも変更される可能性があります。コードとそのデータを地域ごとに分割して、地域固有のビジネスロジックの共有を避けます（最終的にコアコードを共有する場合があります）。

理にかなっていますか？