Implementujesz CQRS i Event Sourcing dla systemu zamówień o wysokiej przepustowości. Polecenia przechowują zdarzenia w strumieniu tylko do dołączania (append-only stream) dla każdego agregatu w Azure Cosmos DB. Musisz zbudować wiele modeli odczytu (zamówienia z możliwością wyszukiwania w Azure SQL i gorącą pamięć podręczną), a także opublikować podzbiór zdarzeń dla zewnętrznych konsumentów do celów analitycznych z możliwością powtórnego odtwarzania. Których dwóch komponentów należy użyć?

1. Użycie procesora zmian Azure Cosmos DB do wyzwalania Azure Functions, które rzutują zdarzenia na modele odczytu, zapewnia efektywne i skalowalne tworzenie modeli odczytu. Idempotentne operacje upsert są kluczowe dla zapewnienia spójności danych, ponieważ procesor zmian może dostarczyć zdarzenia wielokrotnie. 2. Publikowanie wybranych zdarzeń w Azure Event Hubs dla zewnętrznych konsumentów i analityki jest idealne, ponieważ Event Hubs jest zaprojektowany do obsługi dużych strumieni zdarzeń i umożliwia wielokrotne odtwarzanie danych, co jest wymagane dla analityki. Nieprawidłowe opcje: Zapisywanie poleceń bezpośrednio w Azure SQL Database i używanie wyzwalaczy do przesyłania zmian do modeli odczytu zastępuje magazyn zdarzeń, co jest sprzeczne z zasadami Event Sourcing. Użycie Azure Storage Queues jako podstawowego magazynu zdarzeń dla event sourcing jest niewłaściwe, ponieważ kolejki są przeznaczone do krótkotrwałego przechowywania wiadomości, a nie do trwałego strumienia zdarzeń. Wyłączenie idempotencji w projekcjach jest błędem, ponieważ procesor zmian może dostarczyć zdarzenia wielokrotnie, a brak idempotencji doprowadziłby do niespójności danych.