私はこのQAに戻ってきます。そして、私は既存の答えに十分なニュアンスがあるとは思わなかったので、これを追加します。
TL; DR。イベントソーシングの使用状況に応じて、はいまたはいいえ。
私が認識しているイベントソースシステムには2つの主要な種類があります。
ダウンストリームイベントプロセッサ=はい
この種のシステムでは、イベントは現実の世界で発生し、事実として記録されます。製品のパレットを追跡する倉庫システムなど。基本的に競合するイベントはありません。たとえそれが間違っていたとしても、すべてはすでに起こっています。（つまり、パレット123456がトラックAに積まれましたが、トラックBに予定されていました。）その後、レポートメカニズムを介して、例外について例外がチェックされます。Kafkaは、この種の下流のイベント処理アプリケーションに適しているようです。
この文脈では、カフカの人々がイベントソーシングソリューションとしてそれを支持している理由は理解できます。クリックストリームなどですでに使用されている方法とよく似ているためです。ただし、（ストリーム処理ではなく）イベントソーシングという用語を使用している人は、2番目の使用法を参照している可能性があります...
アプリケーション制御の信頼できる情報源=いいえ
この種のアプリケーションは、ユーザーリクエストがビジネスロジックを通過した結果として、独自のイベントを宣言します。この場合、2つの主な理由でKafkaはうまく機能しません。
エンティティの分離の欠如
このシナリオでは、特定のエンティティのイベントストリームを読み込む機能が必要です。これの一般的な理由は、リクエストの処理に使用するビジネスロジックの一時的な書き込みモデルを構築することです。これを行うことはカフカでは非現実的です。エンティティごとのトピックを使用すると、これが可能になる可能性があります。ただし、エンティティが数千または数百万ある場合のスターターではありません。これは、Kafka / Zookeeperの技術的な制限によるものです。
このように一時書き込みモデルを使用する主な理由の1つは、ビジネスロジックの変更を安価で簡単に展開できるようにすることです。
Kafkaでは、代わりにトピックごとのタイプを使用することをお勧めしますが、単一のエンティティのイベントを取得するためだけに、そのタイプのすべてのエンティティのイベントをロードする必要があります。ログの位置では、どのイベントがどのエンティティに属しているかはわかりません。スナップショットを使用して既知のログ位置から開始する場合でも、大量のイベントが発生する可能性があります。
競合検出の欠如
第2に、ユーザーは同じエンティティに対する同時要求が原因で競合状態が発生する可能性があります。競合するイベントを保存し、事後にそれらを解決することは非常に望ましくない場合があります。したがって、競合するイベントを防止できることが重要です。リクエストの負荷をスケーリングするには、条件付き書き込みを使用して書き込みの競合を防止しながらステートレスサービスを使用するのが一般的です（最後のエンティティイベントが#xの場合にのみ書き込み）。別名楽観的同時実行。Kafkaはオプティミスティック並行性をサポートしていません。たとえそれがトピックレベルでそれをサポートしたとしても、それは効果的であるためにエンティティレベルまでずっと下にある必要があるでしょう。Kafkaを使用してイベントの競合を防ぐには、アプリケーションレベルでステートフルなシリアル化されたライターを使用する必要があります。これは重要なアーキテクチャ要件/制限です。
さらに詳しい情報
コメントごとに更新
コメントは削除されましたが、質問は次のようなものでした。その場合、人々は何をイベントストレージに使用するのでしょうか。
ほとんどの人は、既存のデータベースの上に独自のイベントストレージ実装を実装しているようです。内部のバックエンドやスタンドアロン製品などの非分散シナリオの場合、SQLベースのイベントストアを作成する方法が詳しく文書化されています。そして、さまざまな種類のデータベースの上に利用可能なライブラリがあります。この目的のために構築されたEventStoreもあります。
分散シナリオでは、いくつかの異なる実装を見てきました。JetのPantherプロジェクトは、Azure CosmosDBを使用し、変更フィード機能を使用してリスナーに通知します。AWSで聞いたもう1つの類似の実装は、DynamoDBとそのStreams機能を使用してリスナーに通知することです。パーティションキーは、（過剰なプロビジョニングの量を減らすために）最良のデータ分散のためのストリームIDである必要があります。ただし、Dynamoのストリーム全体での完全な再生にはコストがかかります（読み取りおよびコストの面で）。したがって、この実装は、Dynamo StreamsがS3にイベントをダンプするためにも設定されました。新しいリスナーがオンラインになるとき、または既存のリスナーが完全な再生を必要とするとき、最初に追いつくためにS3を読み取ります。
私の現在のプロジェクトはマルチテナントのシナリオであり、私はPostgresの上に自分のプロジェクトを展開しました。Citusのようなものはスケーラビリティに適しているようで、テナント+ストリームごとに分割されます。
Kafkaは、分散シナリオでも依然として非常に役立ちます。各サービスのイベントを他のサービスに公開することは重要な問題です。イベントストアは通常そのために構築されていませんが、それがまさにカフカがうまくやっていることです。各サービスには独自の内部情報源（イベントストレージなど）がありますが、「外部」で何が起こっているかを知るためにKafkaをリッスンします。サービスはまた、イベントをKafkaに投稿して、サービスが行った興味深いことを「外部」に通知する場合もあります。