検証フレームワークは、イベントソーシングの不変の追加専用性と、少なくとも1回の配信およびレガシーシステムのレイテンシの機械的制約との調整に焦点を当てています。インフラストラクチャの配信セマンティクスに依存するのではなく、アプリケーション層でイドポテント保証を確立する必要があります。これにより、重複したKafkaメッセージが副作用なしに同一のイベントストアエントリを生成します。アーキテクチャは、高速取引パスをコンプライアンス報告から切り離し、スピードに最適化されたCQRS読み取りモデルを採用し、重要なパスをブロックせずにレガシーOracle監査リポジトリを水和するために非同期の変更データキャプチャ（CDC）を使用します。
モノリシックなJava EEプラットフォームからSpring Bootマイクロサービスに移行する定量取引企業は、正にこの難題に直面しました。このドメインでは、SEC規則17a-4(b)の監査証跡要件を満たすためにすべての注文修正（価格更新、キャンセル、実行）を不変のイベントとして追跡する必要がありました。しかし、彼らのKafkaクラスタは可用性を優先するために少なくとも1回の配信に設定されており、消費者の再試行ロジックが重複した取引イベントを生成し、ポジション計算を損なうこととなりました。同時に、リスク管理ダッシュボードは、リアルタイムのエクスポージャ計算のために読み取りモデルを照会する際に300ミリ秒のレイテンシスパイクを経験しました。これは、システムがODBCブリッジを介してコンプライアンスOracle 12cデータベースへの同期書き込みを試みていたため、混雑した企業ネットワークを介して50ミリ秒のリスク閾値を違反しました。
ソリューション1: Kafkaでの一回のみセマンティクスを有効にする
チームは、トランザクションIDとイドポテントプロデューサーを使用してKafkaを一回のみ処理（EOS）に再構成することを検討しました。このアプローチは、各メッセージが消費者オフセットとともに原子的にコミットされることを保証することで、プロトコルレベルでの重複を排除します。利点は、アプリケーションコードの変更なしで重複のネイティブ処理を行うことができ、パーティション内の厳密な順序保証を維持できる点です。しかし、欠点は、トランザクション調整のオーバーヘッドがメッセージごとに18-25ミリ秒のレイテンシを追加し、ZooKeeperの依存関係が取引パイプラインをコーディネーター選挙中に停止させる単一障害点を導入したことです。さらに、これは基本的なOracle ODBCボトルネックに対処せず、重複排除の複雑さを上流に移動させるだけでした。
ソリューション2: Cassandraを中間ホットストアとして展開する
代替案として、KafkaとOracleの間にCassandraクラスタを挿入し、高速バッファとして機能させることが提案されました。Apache Spark Streamingは、Cassandraストリームでウィンドウ化された重複排除を実行し、Oracleへのバッチ書き込みを夜間に行いました。利点は、Cassandraがミリ秒レイテンシで高書き込みスループットを処理でき、リアルタイム処理とコンプライアンスストレージを切り離せる点です。しかし、欠点は重要な運用リスクを引き起こしました。2つの異なるストレージシステムを維持することで、ネットワークパーティション中にスプリットブレインシナリオが発生し、SEC監査官は中間可変ストアが不変の監査証跡の信頼できる情報源として機能する能力に懐疑的でした。ポリグロット耐久層全体でACID特性を確保するための複雑さは、プロジェクトのタイムラインに脅威を与えました。
ソリューション3: Redis読み取りモデルとDebezium CDCによるクライアント側のイドポテント性
選択されたソリューションは、イベントハンドラ内で複合自然キー（集約ID + シーケンス番号）を使用してクライアント側のイドポテント性を実装し、重複したKafkaメッセージが認識され、状態の変更なしに破棄されることを保証しました。レイテンシ要件を満たすために、チームはリスク計算のために読み取りモデルを具現化するために各マイクロサービスに密接に配置されたRedisクラスタを展開し、10ミリ秒未満のクエリ応答時間を達成しました。パフォーマンスに影響を与えることなくOracleコンプライアンス要件を満たすために、彼らはDebeziumを実装してイベントストアのPostgreSQLバックエンドデータベースからの変更をキャプチャし、それらを非同期でOracleにストリーム化しました。監査報告のための最終的一貫性を受け入れながら、取引操作には強い一貫性を維持しました。
このアプローチは、インフラストラクチャの制約ではなくアプリケーションロジックを通じて重複イベントリスクに対処し、監査の整合性を犠牲にせずにメモリキャッシングを介して攻撃的なレイテンシSLAを満たし、リアルタイムのクリティカルパスからレガシーOracle投資を切り離したため成功しました。その結果、150,000イベント毎秒を処理し、6ヶ月の運用で重複取引が検出されず、データの不変性や追跡性に関する問題もなくSECの完全なコンプライアンス検証に合格しました。
ネットワークパーティションが発生したとき、イベントソースシステム内で分散集約間でイベントの順序をどのように維持しますか？
候補者はしばしば、グローバルな順序が必要または達成可能であると仮定し、アーキテクチャのボトルネックを生じさせます。分散イベントソーシングにおいて、順序はシステム全体ではなく、集約ルートレベルに厳密にスコープする必要があります。因果関係を確立するために、各集約ストリーム内にベクトルクロックまたは論理的単調シーケンス番号を実装する必要があります。Kafkaパーティションは、プラットフォームのパーティション内順序保証を活用するために、集約境界と1対1で一致させる必要があります。ネットワークパーティション中、システムは異なる集約間の一時的不整合（最終的な一貫性）を受け入れる一方、各集約内で楽観的同時実行制御を使用して強い一貫性を確保し、バージョンチェックを行うことで、分散ロックを必要とせずに更新の喪失を防ぐ必要があります。
イベントソーシングと監査証跡のための変更データキャプチャ(CDC)を単に使用することの建築的区別は何ですか？
多くの候補者はこれらのパターンを混同し、CDCだけが監査要件を満たすと示唆します。CDCはデータベースレイヤーでの状態の変化をキャプチャします（例：「行42がAからBに更新されました」）、一方イベントソーシングは、状態変化が発生する前のビジネスイベントとしてドメインの意図をキャプチャします（例：「顧客がプレミアムティアにアップグレードされました」とコンテキストメタデータ）。SECのコンプライアンスにおいて、イベントソーシングはビジネスの合理性と意思決定のコンテキストを保存するため、優れた監査能力を提供します。取引決定を再構築する際、ドメインイベントは注文が変更された理由を明らかにしますが、CDCログは単に変更が発生したことを示すだけです。イベントストアはレコードのシステムとして機能し、CDCは同期メカニズムとして機能します。
不変イベントストア内でのGDPR第17条（消去の権利）リクエストを、SECの保持義務も満たすことはどう処理しますか？
これは不変性とプライバシー規制との間の根本的な対立を表しています。候補者はしばしばイベントを物理的に削除するか、編集を行うと提案しますが、どちらも監査証跡の整合性に違反します。正しいアプローチは、イベントペイロード内の個人を特定可能な情報（PII）を暗号化し、別のキー管理サービス（KMS）に保存されたデータ暗号化キーを使用することです。消去リクエストが発生した場合、イベントデータを削除するのではなく、暗号化キーを削除することで、PIIを永続的に読めなくしますが、SEC規制に要求されるイベント構造や集約状態遷移は保持されます。代わりに、後続のストリームで敏感なフィールドをトムストーン値で上書きする補償イベントを実装し、監査履歴を維持しながら現在のプロジェクションに回復可能な個人データを含めないようにします。