분산 트랜잭션의 한계와 SAGA 패턴

왜 트랜잭션이 어려워졌을까?

모놀로식 아키텍처에서는 하나의 데이터베이스 내에서 모든 트랜잭션이 수행된다.

이때는 ACID(Atomicity, Consistency, Isolation, Durability) 원칙을 지키며 손쉽게 데이터 일관성을 유지할 수 있다.

 

하지만, MSA(Microservices Architecture)로 전환하면서 상황이 완전히 달라졌다.

서비스가 분리되고, 각 서비스는 자체 데이터베이스를 가지게 되었다.

이제 하나의 요청이 여러 서비스(DB)를 거치며 실행되기 때문에, 기존의 단일 트랜잭션 개념으로는 일관성을 보장하기가 어려워졌다.

 

 

분산 트랜잭션의 문제점

1. 서비스 간 데이터 일관성 붕괴

한 서비스의 작업은 성공했지만 다른 서비스의 작업이 실패하면, 데이터의 일관성이 쉽게 깨진다.

예를 들어 결제는 성공했는데, 재고 차감이 실패한 경우가 있다.

 

2. 2PC(2 Phase Commit)의 비효율성

전통적인 분산 트랜잭션 해결책으로 2PC가 존재하지만, 이는 각 참여 서비스가 트랜잭션 커밋 여부를 조율해야 하므로 성능이 낮고 복잡하다.

MSA의 목표인 독립성과 확장성에서도 어긋난다.

 

3. 확장성과 가용성의 희생

ACID를 완벽히 유지하려면 DB 락(lock)을 유지해야 한다.

하지만 분산 환경에서는 락을 오래 유지하면 성능 저하와 장애 전파로 이어진다.

 

결국 MSA 환경에서는 강한 일관성(Strong Consistency) 대신 최종 일관성(Eventual Consistency)을 추구해야 한다.

 

ACID의 한계 - MSA에서는 통하지 않는다

속성	설명	MSA 환경의 한계
Atomicity	모두 성공 또는 모두 실패	서비스별 독립 트랜잭션으로 불가능
Consistency	데이터 일관성 유지	네트워크 지연, 장애로 일시적 불일치 발생
Isolation	동시 실행 간 간섭 없음	서비스 간 상태 공유 불가
Durability	성공한 트랜잭션은 영구적	분산 환경에서 보장 어려움 (복제 지연 등)

 

즉, ACID는 단일 시스템에서는 완벽하지만, 분산된 시스템에서는 현실적으로 유지하기 어렵다.

 

💡 분산 트랜잭션이란?
분산 트랜잭션(Distributed Transaction)은 말 그대로 여러 시스템(또는 여러 데이터베이스)에 걸쳐 수행되는 하나의 논리적 트랜잭션을 의미한다. 즉, 단일 트랜잭션이 여러 서비스나 DB 노드에 흩어져 있는 데이터를 동시에 수정하거나 관리해야 할 때 사용된다.

하지만 분산 트랜잭션에는 네트워크 지연, 락(lock) 유지, 서비스 간 높은 결합도, 복잡한 복구 절차 등의 문제가 존재한다.
이러한 한계를 해결하기 위해 SAGA, Event Sourcing, CQRS 등과 같은 MSA 환경에 적합한 트랜잭션 관리 기법이 등장했다.

핵심 철학은 다음과 같다.
“완벽한 즉시 일관성을 포기하고, 시간에 따라 정합성을 맞춘다.”

 

---

SAGA 패턴의 등장

SAGA 패턴은 "분산 트랜잭션의 일관성 문제"를 해결하기 위한 현대적 접근 방식이다.

각 서비스가 자신의 로컬 트랜잭션(Local Transaction)을 수행하고, 어떤 서비스에서 실패하면 보상 트랜잭션(Compensating Transaction)을 실행하여 이전 단계의 변경을 되돌린다.

 

 

위 다이어그램에서 각 단계는 서로 독립적으로 실행되며, 각자의 로컬 트랜잭션 단위로 커밋된다.

예를 들어, 재고 서비스에서는 재고 차감에 대한 로컬 트랜잭션이 먼저 수행되고, 정상적으로 완료되면 주문 서비스에서 주문 생성 트랜잭션이 실행된다. 이후 이 과정이 모두 성공적으로 처리되면 결제 서비스에서 결제 처리를 위한 로컬 트랜잭션이 진행된다.

하지만 결제 단계에서 사용자가 결제 화면을 닫거나 네트워크 오류로 인해 결제가 실패할 수도 있다.
이 경우 시스템은 이미 완료된 재고 차감과 주문 생성 작업을 역순으로 되돌리기 위한 보상 트랜잭션(Compensating Transaction)을 실행하여, 전체 시스템을 일관된 상태로 복구한다.

 

즉, SAGA는 "롤백"이 아니라 "보상"으로 일관성을 맞추는 방식이다.

 

SAGA의 핵심 특징 

분산 제어

SAGA 패턴에서는 각 서비스의 트랜잭션을 어떻게 조율하느냐에 따라 두 가지 방식으로 나뉜다.

• 오케스트레이션(Orchestration)
  
  • 중앙에 조정자(Orchestrator)가 존재하며, 각 서비스의 트랜잭션 실행 순서를 제어한다.
  • 즉, 오케스트레이터가 “서비스 A 실행 → 서비스 B 실행 → 서비스 C 실행”처럼 흐름을 명시적으로 관리한다.
• 코레오그래피(Choreography)
  • 중앙 제어자가 없이 각 서비스가 이벤트 기반으로 자율적으로 동작한다.
  • 예를 들어, 주문 서비스가 “주문 생성됨(OrderCreated)” 이벤트를 발행하면, 결제 서비스가 이를 구독하여 결제를 수행하고, 결제 완료 시 “결제 완료됨(PaymentCompleted)” 이벤트를 발행하는 방식

 

보상 트랜잭션(Compensating Transaction)

SAGA의 핵심은 “실패 시 롤백”이 아닌, “보상 트랜잭션을 통한 복구”이다.

 

각 서비스의 로컬 트랜잭션이 성공하더라도, 이후 단계에서 실패가 발생하면 이미 완료된 작업을 되돌리는 보상 트랜잭션이 수행되며, SAGA는 트랜잭션 전체를 되돌리지 않고, 역방향으로 비즈니스 로직을 수행하여 시스템을 일관된 상태로 되돌린다.

 

최종 일관성(Eventual Consistency)

SAGA 패턴은 즉시 일관성(Strong Consistency)을 포기하고, 최종 일관성(Eventual Consistency)을 보장한다.

 

이는 모든 데이터가 즉시 일치할 필요는 없지만, 시간이 지나면 전체 시스템이 일관된 상태에 도달한다는 개념이다.

예를 들어, 주문이 생성된 직후 결제 내역이 잠시 보이지 않더라도 일정 시간이 지나면 모든 서비스의 상태가 일관되게 동기화된다.

 

SAGA의 두 가지 구현 방식

Choreography, Orchestration

 

MSA 환경에서 SAGA 패턴은 서비스 간 트랜잭션을 어떻게 조율하느냐에 따라 크게 두 가지 방식으로 나뉜다.

👉 Choreography(코레오그래피) 방식과 Orchestration(오케스트레이션) 방식

각 방식은 동일한 목표(최종 일관성 유지)를 추구하지만, 트랜잭션 제어 방식과 구조적 특징이 다르다.

 

1. Choreography (코레오그래피)

Choreography Architecture Diagram

 

코레오그래피 방식은 이벤트 기반(Event-driven)으로 서비스들이 자율적으로 협력하는 구조이다.

즉, 중앙 제어자 없이 각 서비스가 자신의 작업을 수행한 뒤 이벤트를 발행(publish)하고, 다른 서비스들이 그 이벤트를 구독(subscribe)하여 다음 단계를 실행한다.

 

예시

1. 주문 서비스 → “주문 생성됨(OrderCreated)” 이벤트 발행
2. 결제 서비스 → 해당 이벤트 구독 후 결제 수행
3. 결제 성공 시 → “결제 완료됨(PaymentCompleted)” 이벤트 발행
4. 배송 서비스 → 이를 구독하여 배송 준비 시작

이처럼 각 서비스가 이벤트를 주고받으며 트랜잭션이 순차적으로 이어진다.

 

장점

• 단순한 구조: 별도의 중앙 관리자가 없어 구현이 간단함
• 확장성 우수: 서비스 간 결합이 느슨해져 독립적인 배포 가능
• MSA 철학에 부합: 각 서비스가 자율적으로 동작

단점

• 이벤트 흐름이 복잡해질 수 있음 (이벤트 폭풍, 순서 보장 어려움)
• 비즈니스 로직 파악이 어려움: 전체 트랜잭션 흐름이 여러 서비스에 흩어짐
• 예외 처리 곤란: 어느 단계에서 실패했는지 추적하기 어려움
• 디버깅 및 모니터링 난이도 높음

 

2. Orchestration (오케스트레이션)

Orchestration Architecture Diagram

 

오케스트레이션 방식은 중앙에 SAGA 오케스트레이터(Saga Orchestrator)가 존재하는 구조이다.

오케스트레이터가 각 서비스의 트랜잭션을 순서대로 호출하고 상태를 관리한다.

 

예시

1. 오케스트레이터 → 주문 서비스 호출 → 성공 시 결제 서비스 호출 → 성공 시 재고 서비스 호출
2. 결제 실패 시 → 이전 단계의 보상 트랜잭션 실행 (예: 주문 취소)

즉, 오케스트레이터가 전체 트랜잭션의 “지휘자(Conductor)” 역할을 한다.

 

장점

• 흐름 제어가 명확: 전체 트랜잭션 단계를 한 곳에서 관리 가능
• 보상 트랜잭션 처리 용이: 실패 시 역순으로 보상 트랜잭션 실행
• 로깅/모니터링 용이: 중앙에서 트랜잭션 상태를 추적 가능

 

단점

• 중앙 집중화: 오케스트레이터가 단일 장애점(SPOF)이 될 수 있음
• 구현 복잡도: 오케스트레이터 로직이 커질수록 관리 부담 증가
• 서비스 간 결합도 증가 가능성

 

Choreography vs Orchestration

구분	Choreography (코레오그래피)	Orchestration (오케스트레이션)
제어 방식	이벤트 기반 자율 제어	중앙 오케스트레이터 제어
구조 복잡도	낮음 (단순한 구조)	높음 (중앙 집중형)
확장성	매우 높음	중간
장애 영향	서비스별 독립 (격리성 높음)	오케스트레이터 장애 시 전체 영향
디버깅/모니터링	어려움 (흩어진 이벤트)	용이 (중앙 제어)
보상 트랜잭션 관리	각 서비스에서 수행	중앙에서 명확히 제어
사용 예	소규모 MSA, 이벤트 중심 시스템	대규모 트랜잭션 관리, 복잡한 비즈니스 로직

코레오그래피 방식은 이벤트 기반으로 서비스 간 결합을 최소화하여 확장성과 유연성을 극대화하는 방식이며,

오케스트레이션 방식은 중앙 제어를 통해 명확한 트랜잭션 제어와 보상 관리가 가능한 방식이다.

 

두 방식은 상호 배타적인 개념으로, 상황에 따라 혼합하여 사용하는 경우도 많다.

 

전통적인 ACID vs SAGA

구분	ACID	SAGA
일관성 수준	강한 일관성, 하나의 트랜잭션이 커밋되는 순간, 모든 데이터는 즉시 일관된 상태가 됨	최종 일관성, 각 서비스가 따로 커밋되지만 보상 트랜잭션과 이벤트 전파를 통해 시간이 지나면 일관성이 맞춰짐
실패 시 처리	트랜잭션 롤백, 어떤 단계에서든 실패하면 전체 트랜잭션을 원자적으로 취소	보상 트랜잭션, 이미 완료된 단계들을 역순으로 취소하는 별도의 비즈니스 로직 실행
구조	단일 DB/시스템 중심, 하나의 애플리케이션과 하나의 데이터베이스 안에서 트랜잭션이 완료됨	서비스 간 분산 구조, 여러 마이크로서비스와 각각의 DB에 걸쳐 로컬 트랜잭션들이 체인처럼 이어짐
성능	느림, 락 기반, 동시성 제어를 위해 레코드/테이블 락을 오래 잡을 수 있어 확장성이 떨어짐	상대적으로 빠름, 비동기 이벤트 기반, 각 단계가 독립적으로 커밋되고, 이벤트를 통해 다음 단계가 트리거되어 락 유지 시간이 짧음
적용 환경	모놀리식 / 단일 DB 시스템, 전통적인 엔터프라이즈 애플리케이션으로 단일 RDBMS 환경	MSA, 클라우드 네이티브 환경, 서비스가 분리되어 있고 각자 DB를 가진 분산 시스템, 대규모 확장 환경

• ACID는 "한 번에, 깔끔하게, 즉시 일관성"을 추구하는 대신 확장성과 분산 환경에 약한 모델
• SAGA는 "시간이 조금 걸리더라도, 보상 로직을 통해 최종적으로 일관성을 맞추는" 모델이라 MSA, 클라우드 네이티브 환경에 더 적합한 트랜잭션 전략

 

---

SAGA의 장점과 단점

장점

1. 성능과 확장성 향상

SAGA 패턴의 가장 큰 강점 중 하나는 성능과 확장성(Scalability)을 해치지 않으면서 분산 트랜잭션 문제를 해결한다는 점이다.

 

1-1. 서비스별 독립적 확장(Independent Scaling)

SAGA는 각 서비스가 자체 로컬 트랜잭션을 처리하기 때문에, 서비스마다 독립적으로 스케일 아웃을 할 수 있다.

 

독립적 확장

 

예를 들어

• 주문 서비스는 8개 인스턴스로 구성
• 재고 서비스는 5개 인스턴스로 구성

 

이처럼 서비스마다 필요한 만큼만 확장할 수 있어 병목이 되는 지점이 줄어든다.

특히 Choreography 방식처럼 중앙 조정자가 없는 경우에는 더욱 확장성이 좋다.

 

1-2. 2PC(2-Phase Commit) 대비 압도적으로 빠름

전통적인 2PC 방식은 다음과 같은 문제가 존재한다.

• 모든 참여 서비스가 동시에 트랜잭션에 참여해야 하고
• 가장 느린 서비스가 전체 성능을 결정하며
• 전체가 하나의 락을 공유하는 것처럼 블로킹된다.

즉, 하나의 서비스가 느리면 전체가 느려지는 구조다.

 

반면 SAGA는

• 서비스가 각자 로컬 트랜잭션을 빠르게 커밋하고
• 다음 단계는 별도로 진행되며
• 실패 시에는 보상 트랜잭션만 수행하면 되기 때문에

느린 서비스가 전체 트랜잭션의 발목을 잡지 않는다.

 

1-3. 긴 트랜잭션 동안 DB 락을 잡지 않음

2PC나 ACID 기반 글로벌 트랜잭션은 트랜잭션이 끝날 때까지 DB 락을 오래 유지한다.

 

그러나 SAGA에서는

• 각 단계는 개별 트랜잭션으로 짧게 끝나고
• 다음 단계는 새로운 트랜잭션으로 이어지므로

DB 락을 오래 유지하지 않는다.

 

그 결과 다음과 같은 장점을 얻는다.

• 동시성 처리 향상
• 성능 저하 방지
• 교착 상태(deadlock) 위험 감소

 

1-4. 비동기 이벤트 기반으로 대량 트래픽 처리에 강함

SAGA는 이벤트 기반(SNS, Kafka 등)으로 처리할 수 있기 때문에

• 서비스 간 결합도가 낮아지고
• 트래픽이 몰려도 큐가 완충 역할을 하며
• 시스템 전체가 느려지지 않고 자연스럽게 버퍼링 가능

즉, 고부하 상황을 더 안정적으로 처리할 수 있다.

 

2. 가용성

SAGA 패턴은 서비스 장애 상황에서도 시스템 전체가 멈추지 않도로 설계되어 있어, 가용성(Availability)을 높이는 데 큰 장점을 가진다.

 

2-1. 서비스 장애가 전체 장애로 이어지지 않음

SAGA는 각 서비스가 독립적으로 동작하며, 특히 이벤트 기반(Message Broker) 방식에서는 비동기로 트랜잭션이 이어진다.

 

따라서 특정 서비스가 일시적으로 장애가 발생하더라도 다른 서비스는 정상적으로 동작할 수 있고 문제 서비스만 복구되면 이후 이벤트를 다시 처리할 수 있다.

 

이는 2PC 방식과의 큰 차이점이다.

(2PC에서는 코디네이터가 죽으면 전체 트랜잭션이 멈춰버려 시스템 전체가 영향을 받는다. 반면, SAGA는 개별 서비스 장애가 전파되지 않는다.)

 

2-2. 새로운 기능 추가나 변경이 용이함 (유연성)

SAGA는 서비스 간 결합이 약하고, 이벤트 기반 구조가 많기 때문에 확장성과 유연성이 뛰어나다.

 

예를 들어, 서비스가 성장해 "쿠폰 기능"을 추가한다고 해보자.

이때 기존 서비스 코드를 수정할 필요 없이, OrderCompleted 같은 기존 이벤트를 새로 만든 쿠폰 서비스가 구독(subscribe)하도록 하면 된다.

 

즉,

• 기존 서비스 변경 없음
• 새로운 기능 추가가 빠르고 안전함
• 이벤트를 소비하는 새로운 서비스만 추가하면 됨

이러한 구조 덕분에 시스템이 커지더라도 유지보수가 훨씬 수월하다.

 

 

단점

1. 복잡성

SAGA 패턴의 가장 큰 약점은 복잡성이 매우 높다는 점이다.

 

1-1. 로컬 트랜잭션 + 보상 트랜잭션 등 모두 구현해야 함

각 단계마다

• 정방향 로컬 트랜잭션
• 실패 시 되돌리는 보상 트랜잭션

두 가지를 모두 설계해야 한다.

즉, 모든 실패 시나리오를 개발자가 직접 고려해야 하는 구조이다.

 

복잡성

 

예를 들어 7단계 SAGA가 존재하는 경우

• 7개의 정방향 트랜잭션
• 7개의 보상 트랜잭션
• 각 단계의 실패, 중간 상태 처리, 멱등성 처리

총 20개에 가까운 로직을 다뤄야 한다.

 

1-2. 도입 난이도가 높고 한 번에 안정화되기 어려움

모든 코드가 그렇지만 SAGA는 단순히 "도입한다"고 해서 바로 안정적으로 동작하지 않는다.

서비스마다 실패 케이스가 다르고, 네트워크 상황, 이벤트 처리 순서 등이 매우 다양하기 때문이다.

 

그래서

• 초기에 크고 작은 오류가 반복적으로 발생하고
• 실패 패턴을 경험하면서 점진적으로 안정화되는 경우가 많다

 

1-3. 코드량 증가 및 유지보수 난이도 상승

ACID 트랜잭션 한 번으로 해결할 수 있는 일을 SAGA에서는 여러 단계로 쪼개 직접 구현해야 한다.

그 결과

• 코드량이 증가하고
• 상태 관리가 복잡해지며
• 신규 입사자가 이해하기까지 시간이 오래 걸린다

 

1-4. 디버깅 난이도 증가

SAGA는 여러 서비스가 분산 환경에서 순차적, 비동기로 동작하기 때문에

• 어느 단계에서 실패했는지
• 어떤 보상 트랜잭션이 끝났는지
• 중복 실행이 있었는지

이런 부분을 추적하는 것이 쉽지 않다.

특히 분산 로그, 트레이싱 시스템(Zipkin, Jaeger)이 없으면 사실상 디버깅이 불가능하다.

 

2. 보상 트랜잭션 설계 난이도

SAGA 가장 어려운 부분 중 하나가 바로 보상 트랜잭션(Compensating Transaction) 설계다.

보상 트랜잭션은 단순한 "롤백"이 아니라, 현실 세계의 비즈니스 규칙을 반영한 되돌리기 작업이기 때문이다.

 

2-1. 되돌릴 수 없는 작업이 존재한다.

모든 작업을 ACID처럼 그대로 원상복구할 수 있는 것은 아니다.

보상 트랜잭션 어려움

 

예를 들어

• 이미 발송된 이메일은 취소가 불가능하며 -> "취소 안내 메일"로 대체해야 할 수 있다
• 외부 API 호출 결과는 통제할 수 없고 -> 보상도 외부 시스템 정책에 따라 달라진다
• 배송이 이미 시작된 경우 -> 단순 취소가 아니라 "반품 프로세스"로 전환해야 한다

이처럼 도메인 정책을 바탕으로 사람의 경험과 판단이 필요한 로직이 많다.

 

2-2. 모든 실패 케이스를 한 번에 설계하기 어려움

서비스마다 실패 원인과 시나리오가 다양하고, 특히 분산 환경에서는 네트워크 문제까지 겹치면서 개발자가 모든 케이스를 처음부터 완벽하게 설계하기 어렵다.

 

결국 SAGA는

• 실제 운영 경험
• 누적된 장애 상황 분석
• 점진적 보완

을 통해 안정화되는 패턴이다.

 

2-3. 중간 상태(Intermediate State)가 노출될 수 있는 문제

SAGA는 여러 개의 로컬 트랜잭션으로 구성되므로, 각 단계 사이에 중간 상태가 시스템 외부에 노출될 수 있다.

 

그 결과

• UI에서 잘못된 정보를 표시하거나
• 다른 서비스가 중간 상태 데이터를 읽어버리거나
• 비즈니스 로직이 예상치 못한 상태에서 실행되는 문제

가 발생할 수 있다.

 

이 문제를 막기 위해서는

• "예약됨(RESERVED)" 같은 중간 상태를 명확히 정의하고
• 조회 API에서 중간 상태를 숨기거나
• 읽기 모델(read model)을 분리하는 등의 추가 설계가 필요하다.

 

---

이러한 SAGA 패턴을 적용하기 적합한 경우 / 부적합한 경우는 언제일까?

적합한 경우

SAGA 패턴은 모든 분산 시스템에 무조건 적용되는 만능 해법이 아니다.

아래 조건을 순차적으로 만족하는 경우 SAGA는 큰 효과를 낼 수 있다.

 

SAGA 패턴 사용 유무 검토

 

1. MSA(마이크로서비스 아키텍처) 환경일 때

SAGA는 기본적으로 각 서비스가 독립적인 DB를 가지는 MSA 환경을 위해 고안된 패턴이다.

• 여러 서비스가 하나의 비즈니스 흐름에 참여한다.
• 각 서비스가 자체적인 로컬 트랜잭션을 수행한다.

만약 모놀로식 아키텍처라면 ACID 트랜잭션이 더 단순하고 안전하다.

 

2. 강한 일관성이 반드시 필요한 상황이 아닐 때

SAGA는 즉시 일관성(Strong Consistency) 대신 최종 일관성(Eventual Consistency) 모델을 사용한다.

 

따라서 아래 상황에서는 적합하지 않다.

• 은행 계좌 이체처럼 즉각적이고 강력한 일관성이 필수인 경우
• 중간 상태가 노출되면 안 되는 보안, 승인 업무

그러나 대부분의 일반 서비스에서는 잠시 불일치가 발생하더라도 문제가 되지 않기에 SAGA를 통한 확장성, 가용성 확보가 더 큰 장점이 된다.

 

3. 보상 트랜잭션(Compensating Transaction)을 설계할 수 있을 때

SAGA의 핵심은 실패 시 되돌리는 "보상 트랜잭션"이다.

 

예시

• 재고 차감 실패 -> 재고 복구
• 결제 실패 -> 결제 취소
• 주문 실패 -> 주문 취소

만약 해당 단계의 작업을 "되돌릴 수 없는 작업"이라면 SAGA 패턴의 사용이 어려워진다.

 

4. 높은 가용성과 확장성이 필요한 경우

서비스 전체가 빠르게 응답하고, 대량 트래픽을 처리해야 하며, 각 서비스가 독립적으로 확장할 수 있어야 한다면 SAGA가 이상적이다.

• 각 서비스가 독립적으로 확장(Scale-out) 가능
• 긴 트랜잭션 처리 중에도 데이터베이스 락을 오래 잡지 않음
• 병목 지점(Coordinator 단일 실패 지점)을 만들지 않을 수 있음

결국 가용성과 확장성 요구가 높은 MSA에서는 SAGA의 장점이 극대화된다.

 

 

부적합한 상황

1. 즉각적, 강한 일관성이 필요한 도메인

예시

• 은행 송금 처리 -> 잔액이 즉시 정확해야 하며 중간 상태가 노출되면 치명적
• 재무 회계 처리 -> 수치 오차가 절대 허용되지 않는 시나리오

이러한 시스템은 SAGA의 "최종 일관성" 모델이 적합하지 않다.

 

2. 격리성이 반드시 보장되어야 하는 작업

동시성 문제로 인해 중간 상태가 노출되거나 dirty read/uncommitted read가 발생하면 안 되는 경우

 

예시

• 재고 수량이 실시간으로 강하게 보호되어야 하는 경우 (중복 예약 불가)
• 민감한 승인 프로세스 (exl 출입 통제 승인, 민원 승인 등)

 

3. 트랜잭션이 단일 DB 안에서 해결되는 경우

보상 트랜잭션이 불가능한 경우 SAGA는 적합하지 않다.

 

예시

• 문자 메시지 / 푸시 알림 발송 (취소 불가 -> 대체 보상 로직 필요)
• 실시간 교통카드 결제처럼 이미 처리된 외부 시스템 호출
• 물리적 프로세스 (ex. 로봇 또는 기계 명령, 생산라인 작업)

이러한 작업은 SAGA의 "논리적 되돌리기"가 불가능하거나 매우 복잡해진다.