従来型とESの違い
まずは、言葉の定義から。
ここでいうデータ品質とは、分析系のデータではなく、業務トランザクション系のデータを指しています。
マイクロサービス環境において、イベントソーシング（ES）とそうではない従来の状態指向（CRUD）実装とでは、担保できるデータ品質のレベルと性質に、根本的な差が生まれます。
結論から言うと、ESはデータ品質を設計によって内蔵するのに対し、従来型は規律と実装によって維持しようとします。
では、まずそれぞれの実装でのデータ品質の特徴の違いを見ていきましょう。
従来の状態指向（CRUD）実装の場合
完全性
低い傾向にある
システムは基本的に「最新の状態」のみを記録し、
「どのようにその状態に至ったか」という変更の履歴や文脈は失われます。
データの完全性を担保するには、アプリケーションログや別途設計された監査ログテーブルに依存する必要があり、実装が煩雑になりがちです。
監査性
限定的であり、高コスト
監査証跡は、DBトリガーやアプリケーションのロギングといった後付けの仕組みで構築されるため、不完全になるリスクがあります。
信頼できる監査証跡を確保・維持するためのコストが高くなります。
正確性・信頼性
アプリケーションの実装に依存する
アプリケーションの実装に強く依存します。
バグのあるコードが一度でもデータを更新（UPDATE）してしまうと、そのデータは恒久的に破損する可能性があります。
何が原因でデータが不正確になったのかを後から追跡するのは非常に困難です。
障害からの回復力
複雑になる傾向がある
マイクロサービス間でデータ不整合が発生した場合、どちらが正しい状態かを判断し、
手動でデータを修正するといった、複雑な回復作業が必要になることがあります。
イベントソーシング（ES）実装の場合
完全性
非常に高いレベルで保証される
これが最も直接的なメリットです。
全ての状態変化がイベントとして記録されるため、ビジネスプロセスの全履歴が完全に保存されます。
データが「欠落する」という概念が基本的に存在しないため、データの完全性が非常に高くなります。
イベントソーシングは、ビジネスプロセスで発生した全ての状態変化を、余すことなくイベントとして記録します。
監査性
ネイティブであり、低コスト
イベントストリームは、それ自体が完璧な監査証跡として機能します。
「いつ、誰が、何をしたか」という変更の全履歴が、改ざん不可能な形で保存されているため、監査性が極めて高くなります。
正確性・信頼性
非常に高いレベルで保証される
イベントは「起きた事実」として不変なため、データの真実性は汚されません。
そのため、後からデータを更新する際に発生しがちな、意図しない上書きや計算ミスといった人為的なエラーが介在する余地がありません。
もし状態を計算・表示するロジックにバグがあっても、バグを修正後にイベントを再生すれば、100%正確な状態を後からいつでも復元できます。
適時性
最新の状況に基づいた意思決定が可能
イベントは発生した瞬間に記録され、リアルタイムで他のシステムに連携（イベントストリーミング）することが可能です。
これにより、データの鮮度が高く保たれ、常に最新の状況に基づいた意思決定が可能になります。
障害からの回復力
高い回復力をもつ
イベントストリームという単一の信頼できる情報源（Single Source of Truth）から、各サービスが自身の状態（データストア）を何度でも再構築できます。回復プロセスが明確であり、自動化も容易です。
ESに変えることに伴うデメリット
イベントソーシングの最大のデメリットは、その強力なデータ品質保証と引き換えに、
アーキテクチャ全体の複雑性が大幅に増大する点に集約されます。
シンプルに学習コストが高いというか、従来のモデリング手法に慣れ過ぎて、
違うパラダイムにサクッと乗り換えるのに抵抗あると、なかなか慣れるまでに時間がかかります。
1. 技術的な複雑性と高い学習コスト
思考モデルの変化
開発者は、データを「上書き可能な最新の状態（CRUD）」として扱うことに慣れています。
イベントソーシングは、「変更不可能な事実の連鎖」としてデータを扱うため、
全く異なる思考モデルへの切り替えが必要となり、高い学習コストを要します。
CQRSの必要性
イベントストアは書き込みと履歴再生には最適ですが、「現在の状態」を直接クエリするには不向きです。
そのため、クエリ専用のデータストア（リードモデル）を別途構築するCQRSパターンの採用がほぼ必須となり、アーキテクチャ全体の複雑性が増大します。
2. イベントスキーマのバージョン管理
不変性の呪縛
一度記録したイベントは変更できません。
しかし、ビジネスの成長と共に、イベントに含めたい情報が変わる（フィールドを追加・変更したい）ことは頻繁にあります。
バージョン管理の責務
過去のバージョンのイベントをアプリケーションが正しく解釈し続けられるように、
イベントのバージョン管理の仕組みを自前で実装・運用する必要があり、これは長期的に大きな負担となります。
3. データのクエリと分析の難しさ
アドホックなクエリの困難さ
リレーショナルデータベースであれば簡単な「特定の条件を満たすユーザー全員の現在の状態を一覧する」といったクエリが、イベントストアに対して直接実行するのは非常に困難です。これも、CQRSとリードモデルが必要になる一因です。
4. 結果整合性に伴う課題
リードモデルの遅延
イベントが書き込まれてから、それがリードモデルに反映されるまでには、僅かながら遅延が発生します。
ユーザーがデータを更新した直後にその結果を参照しようとすると、古い情報が表示される可能性があり、UI/UX上でその非同期性を考慮した設計が必要になります。
5. 個人情報の取り扱い
「忘れられる権利」との相性
GDPRなどで定められた「忘れられる権利」は、ユーザーデータの削除を要求します。
しかし、イベントは「不変」であり、削除を前提としていません。
この問題に対処するには、個人情報部分だけを暗号化し、鍵を破棄する（クリプトシュレッディング）など、非常に高度な設計が必要になります。
まとめ
従来の実装では、データ品質は開発者の規律や厳格なテスト、そして堅牢なトランザクション制御によって「守るべきもの」です。一度壊れると、その修復は困難を極めます。
一方でイベントソーシングは、全ての履歴を真実として保存することで、
データ品質を「壊れようがないもの」として扱います。
もし表面的な状態（ビューモデル）がバグによって不正確になっても、
いつでも真実（イベント）から再構築できるという安心感が、マイクロサービスのような複雑な環境において、システム全体の信頼性を根本的に高めるのです。