강의

멘토링

커뮤니티

인프런 커뮤니티 질문&답변

정인호님의 프로필 이미지
정인호

작성한 질문수

장애를 허용하는 견고한 시스템 만들기

DLQ(Dead Letter Queue)와 순서 보장

안녕하세요 강사님 질문 있습니다.

작성

·

11

·

수정됨

0

안녕하세요. 강사님 강의 잘 들었습니다.

한가지 질문이 있습니다.

주문 생성과 주문 처리api를 나누고 사용자가 결제가 되면 주문 처리 api를 호출하는걸로 알고있습니다.

Orchestaration 방식으로 처리할 때 OrderConfirmEvent를 발행하면 제 서비스로 예를 들면 재고, 쿠폰, 적립금 서비스에서 consume하여 처리를 하고 있습니다.

그런데 주문 처리 api에서 재고는 처리되었지만 쿠폰은 실패할 경우 어떻게 보상 트랜잭션을 주어야할지 모르겠습니다.

결제가 된 주문이라 바로 보상을 하는것 보다는 dlt topic에 넣고 재처리를 하고 만약 재시도 3번을 하고 나서 실패할 경우 환불을 해줘야할까요?

주문 처리 api에서는 어디가 실패한지 모르니까요 혹시 어떤식으로 해야할지 조언좀 받을수 있을까요?

답변 1

0

안녕하세요, 인프런 AI 인턴입니다. 정인호님.

주문 처리 과정에서의 분산 트랜잭션 처리와 실패 시 보상 트랜잭션 전략에 관한 질문을 주셨군요. 이 문제는 여러 서비스 간의 복잡한 연동과 데이터 일관성을 유지하기 위한 중요한 도전 과제입니다. 아래에 핵심적인 해결책을 요약해서 설명드리겠습니다.

분산 트랜잭션에서의 재시도 및 보상 트랜잭션

  1. 재시도 메커니즘: 주신 대로, 실패 시 DLT(Dead Letter Topic)에 메시지를 저장하고 재시도하는 방식은 일반적인 방법입니다. 구체적으로는,

    • 이벤트가 실패했을 경우 곧바로 DLT에 저장하기보다는 우선 일정 횟수(예: 3번)까지 재시도를 하되,
    • 각 재시도 시 전이중 실패의 원인을 파악하여 로깅하고, 원인이 해결되지 않을 경우 다음 시도로 넘어갑니다.
  2. 보상 트랜잭션: 일부 서비스가 실패하여 보완이 필요할 경우, 보상 트랜잭션을 통해 롤백하는 접근법이 필요합니다.

    • 부분적 처리: 예를 들어, 재고는 성공했으나 쿠폰 처리가 실패한 경우, 사용자가 인사이트를 얻을 수 있도록 알림을 보내고, 해당 오류를 사용자에게 즉시 고지하는 것이 좋습니다.
    • 최종 실패 시: 재시도 이후에도 모든 처리를 완료할 수 없는 경우, 전체 주문을 보상 처리하거나, 예외 처리를 통해 환불 절차를 수행합니다.
  3. 상태 관리 및 모니터링: 서비스들 간의 상태를 잘 추적할 수 있도록 각 서비스의 처리 상태를 중앙에서 관리하여, 어느 시점에 어떤 서비스가 실패했는지 쉽게 파악할 수 있게 해야 합니다. 이를 위해:

    • 서비스 메시징 체계에서 상태 변화의 로그를 유지하여 빠르게 분석할 수 있도록 합니다.
    • 실시간 모니터링을 통해 각 프로세스의 오류를 관찰하고, 적절히 대응할 수 있도록 시스템 알람을 설정합니다.

관련하여 유사한 주제를 다룬 기존의 질문들을 참고할 수 있습니다:

기존 답변에서 더 많은 인사이트를 얻을 수 있을 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로서는 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

정인호님의 프로필 이미지
정인호

작성한 질문수

질문하기