앞에서 미뤄 둔 설명을 이제 본격적으로 회수한다

chap01에서는 서비스가 나뉘면 부분 성공과 부분 실패를 어떻게 다룰 것인가라는 문제를 봤다.

그때는 수동 보상 처리 수준에서 문제의식만 잡고 넘어갔다.

하지만 chap03에서는 메시지 기반 협업이 본격적으로 들어온다.

이 순간부터는 그 문제를 더 구조적으로 설명해야 한다.

바로 여기서 Saga라는 개념이 본론에 들어온다.

Saga는 무엇을 해결하려고 하는가

Saga를 이 장 수준에서 아주 단순하게 말하면,

여러 서비스에 걸친 긴 흐름을 단계별로 진행하고, 실패하면 이미 성공한 단계를 되돌리는 방식이라고 이해하면 된다.

즉, 하나의 거대한 분산 트랜잭션을 기대하는 대신,

• 단계를 나눠서 진행하고
• 각 단계의 성공/실패를 보고
• 실패하면 보상 작업을 연결하는 방식이다

이 장의 주문 생성 흐름이 바로 그런 구조를 보여 준다.

왜 chap03에서야 이 설명이 필요해질까

chap01에서는 주문 서비스가 직접 외부 HTTP 호출을 하며 보상을 시도했다.

그 구조만으로도 문제는 보였지만, 아직 흐름 전체를 조율하는 구조는 약했다.

반면 chap03에서는:

• 이벤트가 오간다