주문 서비스는 먼저 주문 및 주문 생성 사가 오케스트레이터를 생성합니다. 이후 별 문제가 없다면 다음과 같이 진행될 것입니다.

1. 사가 오케스트레이터가 소비자 확인 커맨드를 소비자 서비스에 전송합니다.

2. 소비자 서비스는 소비자 확인 메시지를 응답합니다.

3. 사가 오케스트레이터는 티켓 생성 커맨드를 주방 서비스에 전송합니다.

4. 주방 서비스는 티켓 생성 메시지를 응답합니다.

5. 사가 오케스트레이터는 신용카드 승인 메시지를 회계 서비스에 전송합니다.

6. 회계 서비스는 신용카드 승인됨 메시지를 응답합니다.

7. 사가 오케스트레이터는 티켓 승인 커맨드를 주방 서비스에 전송합니다.

8. 사가 오케스트레이터는 주문 승인 커맨드를 주문 서비스에 전송합니다.

 

제일 마지막 단계에서 사가 오케스트레이터는 (자신도 주문 서비스의 한 컴포넌트이지만) 커맨드 메시지를 주문 서비스에 전송합니다. 물론 주문 생성 사가가 주문을 직접 업데이트해서 승인 처리해도 되지만, 일관성 차원에서 주문 서비스가 마치 다른 참여자인 것처럼 취급하는 것입니다.

그림 4-6은 다양한 사가 시나리오 중 하나에 불과합니다. 주문 생성 사가의 경우 크게 네 가지 시나리오를 생각해 볼 수 있을 것입니다. 방금 전 살펴본 정상 케이스 외에 소비자 서비스, 주방 서비스, 회계 서비스 중 한곳에 오류가 발생하여 사가가 실패하는 경우가 3개 더 있겠죠. 그래서 가능한 모든 시나리오를 기술하는 상태 기계로 사가를 모델링하면 유용합니다.