Sie implementieren CQRS und Event Sourcing für ein Hochdurchsatz-Bestellsystem. Befehle speichern Ereignisse in einem nur-anhängbaren Stream pro Aggregat in Azure Cosmos DB. Sie müssen mehrere Lesemodelle (durchsuchbare Bestellungen in Azure SQL und einen Hot Cache) erstellen und auch eine Untermenge von Ereignissen an externe Konsumenten für Analysen mit Replay-Fähigkeit veröffentlichen. Welche zwei Komponenten sollten Sie verwenden?

Der Azure Cosmos DB Change Feed Processor ist ideal, um Änderungen (Ereignisse) aus Cosmos DB in Echtzeit zu erfassen und Azure Functions auszulösen. Diese Functions können dann die Ereignisse in verschiedene Lesemodelle (z. B. Azure SQL für durchsuchbare Daten und Azure Cache for Redis für einen Hot Cache) projizieren. Idempotente Upserts sind entscheidend, um Konsistenz bei potenziellen Wiederholungen oder Neuanläufen des Change Feed zu gewährleisten. Azure Event Hubs ist die passende Wahl, um eine Untermenge von Ereignissen an externe Konsumenten für Analysen zu verteilen. Es bietet hohe Durchsatzfähigkeit und die Möglichkeit, die Aufbewahrungsdauer zu konfigurieren, was Replay-Fähigkeiten für historische Analysen ermöglicht. Das direkte Schreiben von Befehlen in Azure SQL und die Verwendung von Triggern ersetzt den Event Store und widerspricht dem Event Sourcing-Muster. Azure Storage Queues sind keine geeignete primäre Event Store-Lösung für Event Sourcing, da sie keine dauerhafte, geordnete Speicherung von Ereignisströmen bieten. Das Deaktivieren der Idempotenz ist riskant, da der Change Feed keine einmalige Zustellung garantiert und dies zu inkonsistenten Lesemodellen führen kann.