두가지 스타일

1. 오케스트레이션(Orchestration)
   • 중앙의 Saga 컴포넌트(오케스트레이터)가 각 서비스에 “다음 작업” 명령을 보내고 결과를 감시
2. 코레오그래피(Choreography)
   • 서비스들이 이벤트를 발행(publish)하고, 다른 서비스가 그 이벤트를 듣고(consume) 자기 일을 처리

---

왜 사용할까?

→ 보통 서비스들은 분산되어있는데, 이 서비스들이 하나의 트랜잭션처럼 동작해야되는 상황들이 있다. MSA 환경에서는 이를 일관되게 처리하기 어려워서 이를 해결하기위해 SAGA패턴을 사용한다

어떻게 동작할까?

→ 일련의 작은 트랜잭션으로 대규모 트랜잭션을 나눈다.

→ 이 작은 트랜잭션들은 독립적으로 커밋되고, 중간에 실패 발생시 보상 트랜잭션을 실행하여 상태를 이전으로 복구한다

SAGA패턴외에도 2PC방식도 씀

구분	2PC (Two-Phase Commit)	Saga + RabbitMQ (분산 트랜잭션 대체)
트랜잭션 경계	글로벌 트랜잭션 (각 서비스의 로컬 트랜잭션을 하나로 묶음)	로컬 트랜잭션들의 연속 (각 서비스는 자체 트랜잭션만 수행)
일관성 모델	강력한 일관성 (원자성 보장)	최종적 일관성 (Eventual Consistency)
실행 흐름	1) PREPARE 요청 → 2) 각 서비스 준비 완료 → 3) COMMIT/ROLLBACK 요청	1) 서비스 A 로컬 커밋 → 이벤트 발행(order.created)
→ 2) 서비스 B 처리 → 이벤트 발행(inventory.reserved) …
리소스 잠금	서비스 간 리소스를 장시간 락	로컬 트랜잭션만 락 → 서비스 간 메시지 큐로 비동기 분리
장애 복구	코디네이터 장애 시 교착 가능성 (Blocking)	실패 단계에서 보상 트랜잭션(Compensation) 호출로 이전 상태 복구
성능·확장성	트랜잭션 완료까지 모든 서비스 대기 → 느리고 확장 어려움	비동기 메시징 기반 → 서비스별 독립 확장·배포 용이
구현 복잡도	XA 드라이버 설정, 글로벌 트랜잭션 매니저 필요	메시지 큐(RabbitMQ)·오케스트레이터 또는 이벤트 흐름 설계 필요