私たちは、Kafka に依存して、私の会社でイベント ソース システムを構築しています。
GDPR に準拠するには、イベントを更新できる必要があります。
私たちのアイデアは、圧縮機能と廃棄機能を使用することです。
これは、(特定のメッセージを上書きするために) 各メッセージに一意のキーを持たせる必要があるため、デフォルトのパーティショニング戦略を使用できないことを意味しますが、同じ集約で発生するイベントは同じパーティションで終了する必要があります。
これにより、カスタム パーティショナーが作成されます (基本的には、既定のパーティショナーの "ハッシュ モジュロ" ロジックをコピーしますが、メッセージ キーとは異なる値を使用してハッシュを計算します)。
問題は、私たちがポリグロット環境で進化していることです (イベントを発行および消費する php、python、および Java/Kotlin サービスがあります)。
これらすべてのサービスが、特定のパーティション キーを指定して同じパーティションにメッセージを生成するようにしたいと考えています (異なるサービスが同じトピックにイベントを発行する場合)。
私たちの主なアイデアは、一般的なハッシュ アルゴリズムを使用することでしたが、(実験的なライブラリの一部ではなく) 強力な配布保証と優れた安定性の両方を備えたものを見つけるのは困難でした。
PHP はネイティブで幅広いハッシュ アルゴリズムをサポートしていますが、他の言語で同じサポートを見つけるのは困難です。
Kafka のデフォルトのパーティショナーは murmur2 に依存しているため、その方向にも目を向け始めました。残念ながら、php ではネイティブにサポートされていません (ただし、いくつかの実装は存在します)。さらに、このアルゴリズムはシードを使用します。つまり、すべてのパブリッシャー サービスにまったく同じシードを使用する必要があり、アプローチが非常に複雑に見え始めています。
ただし、設計を間違った角度から見ている可能性があります。ポリグロット サービス間でイベント ストア書き込み機能を共有することはお勧めできません。「集約ごとに 1 つのパーティション」という要件が保証される限り、各サービスは独自のパーティショニング ロジックを持つことができます。問題は、これを前もって考えなければならないということです。なぜなら、技術的な安全策では、将来、あるサービスが「共有」イベント ストリームで公開されるのを防ぐことはできないからです (そして、まったく同じパーティショニング ロジックを使用しないと、それが発生したときに大きな影響を与えることになります)。
ポリグロット環境で Kafka を使用してイベント ストアを構築した経験のある方がいらっしゃいますか?この特定のトピックについて強調していただけますか?