1つのDBに書き込めるシステムは1つに集約する大切さ

採用しているアーキテクト関係なく、各社各チームが大切にしている事だと思いますが
1つのDBに書き込めるシステムは1つに集約する 事が、データ運用上とてもとても大切な事だと考えています。
最近はマイクロサービスやサーバーレス等で複数のシステムが同じDBを参照する事が増えてきたかと思います。
開発効率向上が見込めるので、良い流れだと思っていますが気をつけなければいけない事もあると思います。

事例

システムA が DB1 に直接書き込んでいる
システムB が DB1 に直接書き込んでいる

という状況が起きたら危険信号だと思っています。
例えばクライアントとサーバーで両方DBに直接書き込んでいる等

これは データ不整合 というサービス運用上最悪レベルの障害を引き起こしかねない状況だと思っています。

上記で想定される障害

• 障害が発生した時に、どのシステムがおかしいか特定ができなくて、無駄に調査時間を食う
• システムAを改修したけど、システムBの改修を忘れて、違う内容のデータが書き込まれてしまった
• システムAで障害が発生して止めたけど、システムBを止め忘れて障害が継続してしまった
• システムAとシステムBで別の型（例えばintとfloat）で書き込んでnumericのカラムに複数の型が入ってしまい、分析DB等の型に厳密なDBにエクスポート時に別データとして扱われ重複が起こる

上記が起きないためには？

シンプルに 1つのDBに書き込めるシステムは1つに集約する のみだと思います。

システムA が システムCに依頼して DB1 に直接書き込んでいる
システムB が システムCに依頼して DB1 に直接書き込んでいる

または

システムA が DB1 に直接書き込んでいる
システムB が システムAに依頼して DB1 に直接書き込んでいる

これで何か障害があったら システムC で一次対応を行い、アクセスログから システムA なのか システムB なのかを判定すれば良いです。
またシステムC内で複数種類の言語を使うとか無いので、型が状況によって変わる等も無いかと思います。

まとめ

上記は最近になって出てきたノウハウではなく、昔からあるノウハウです。
どんなに新技術が出て開発手法が変わったとしても、培われてきた基礎やノウハウは変わらず大事で、役に立つと思います。
流行りを追うばかりではなく、新旧問わず現場のノウハウを吸収し、実践し、現場に合わせて改良したり取捨選択していく事が、良いシステムを構築する近道だと思います。