delivery-server가 정상 Flow의 가장 마지막에 위치하기 때문에, 배송 서비스의 보상 트랜잭션 작업을 하게 되면 다른 서버에서도 추가 작업은 필수로 요하게 된다.
때문에, 타 서비스의 기능 고도화 작업이 이루어지는 동안, delivery-server에서는 주문 취소 시의 Flow에 대한 트랜잭션을 추가하는 작업부터 하기로 결정.
작업 방향:
order-server에서 주문 취소 이벤트 추가 발행 → delivery-server에서 해당 이벤트 구독
order-server 성공 → hub-server 성공 → delivery-server 실패
이 시나리오의 보상 트랜잭션 작업 예정.
이 때 꼭 가져가야 할 것이 outbox/inbox이다.
outbox에서 kafka 이벤트를 발행하고, 실패 시에도 주기적인 retry를 시도할 수 있다.
다만, 이렇게 되면 모든 서비스에서 추가적인 작업이 필요해지기 때문에, 팀원들과 의논 후 개발 일정을 정하는 것이 좋겠다고 판단된다.


➡️ 결론: order-server쪽 동시성 제어 하는 동안, case1의 보상 트랜잭션부터 마련하고 있자. 다음 과정으로 추후에 같이 outbox/inbox 도입하는 것이 베스트
case 3의 경우 추후에 작업 및 블로깅 예정