높은 처리량의 주문 시스템에 CQRS 및 이벤트 소싱을 구현하고 있습니다. 명령은 Azure Cosmos DB의 집계별 추가 전용 스트림에 이벤트를 저장합니다. 여러 읽기 모델(Azure SQL의 검색 가능한 주문 및 핫 캐시)을 구축해야 하며, 재생 기능이 있는 분석을 위해 외부 소비자에게 이벤트의 하위 집합을 게시해야 합니다. 어떤 두 가지 구성 요소를 사용해야 합니까?

CQRS 및 이벤트 소싱 패턴에서 읽기 모델을 업데이트하는 것은 이벤트 스트림을 소비하여 데이터를 프로젝션하는 방식으로 이루어집니다. Azure Cosmos DB 변경 피드 프로세서는 Cosmos DB의 추가 전용 이벤트 스트림에서 이벤트를 안정적으로 읽고, Azure Functions를 트리거하여 Azure SQL Database 및 Azure Cache for Redis와 같은 읽기 모델에 멱등성 upsert를 통해 데이터를 프로젝션하는 데 적합합니다. 멱등성은 중복 이벤트 처리 시 데이터 일관성을 보장합니다. 외부 소비자와 분석을 위해 이벤트의 하위 집합을 게시하려면 Azure Event Hubs가 적합합니다. Event Hubs는 높은 처리량과 거의 실시간 처리를 지원하며, 제한된 보존 기간 동안 이벤트를 재생할 수 있어 분석 및 외부 통합에 유용합니다. Azure SQL Database에 직접 쓰거나 Azure Storage Queues를 기본 이벤트 저장소로 사용하는 것은 이벤트 소싱 패턴의 핵심 원칙인 변경 불가능한 이벤트 스트림 저장과 일치하지 않습니다. 변경 피드가 한 번만 전달을 보장하더라도, 시스템 오류나 재시도 시 중복 처리가 발생할 수 있으므로 멱등성을 비활성화하는 것은 데이터 불일치를 초래할 수 있습니다.