• 단순함: 비즈니스 객체를 생성, 수정, 삭제할 때 서비스가 이벤트를 발행합니다.

• 느슨한 결합: 참여자는 이벤트를 구독할 뿐 서로를 직접 알지 못합니다.

• 이해하기 어렵다: 오케스트레이션 사가와 달리, 사가를 어느 한곳에 정의한 것이 아니라서 여러 서비스에 구현 로직이 흩어져 있습니다. 어떤 사가가 어떻게 작동되는지 개발자가 이해하기 어려운 편입니다.

• 서비스 간 순환 의존성: 참여자가 서로 이벤트를 구독하는 특성상, 순환 의존성(cyclic dependency)이 발생하기 쉽습니다. 그림 4-4도 가만 보면 순환 의존성(주문 서비스 → 회계 서비스 → 주문 서비스)이 형성되어 있습니다. 이것이 반드시 문제라고 할 수는 없지만, 순환 의존성은 잠재적인 설계 취약점입니다.

• 단단히 결합될 위험성: 사가 참여자는 각자 자신에게 영향을 미치는 이벤트를 모두 구독해야 합니다. 이를테면 회계 서비스는 소비자 신용카드를 과금/환불 처리하게 만드는 모든 이벤트를 구독해야 합니다. 따라서 이 서비스는 주문 서비스에 구현된 주문 주기와 맞물려 업데이트되어야 하는 위험이 있습니다.