DB 저장과 이벤트 발행을 함께 믿게 만드는 아웃박스 패턴

주문은 DB에 저장됐는데 이벤트 발행이 실패하면 후속 시스템이 주문을 모를 수 있습니다. 반대로 이벤트만 먼저 나가면 존재하지 않는 주문을 처리할 수 있습니다.

데이터 흐름의 경계를 확인한다

DB 기록과 메시지 브로커 전송은 서로 다른 시스템이므로 하나의 일반 트랜잭션으로 묶기 어렵습니다. 애플리케이션이 DB 저장 직후 바로 발행하면 그 사이에 장애가 날 수 있습니다. 실패 구간을 명시적으로 모델링해야 합니다.

실패와 중복 처리를 정한다

아웃박스 패턴은 주문 데이터와 발행할 이벤트를 같은 DB 트랜잭션에 저장합니다. 별도 전달기가 아웃박스를 읽어 브로커로 보냅니다. 이렇게 하면 DB 저장과 이벤트 기록의 원자성을 확보할 수 있지만 전달 자체는 중복될 수 있습니다.

작은 범위에서 재처리한다

이벤트 ID와 집계 대상 ID를 함께 둡니다. 전달기가 전송 후 확인 전에 죽으면 같은 이벤트를 다시 보낼 수 있으므로 구독자에 멱등성이 필요합니다. 아웃박스 청소 주기도 재전송과 감사 요구를 고려해 정합니다.

지연과 불일치를 관측한다

미발행 아웃박스 수, 가장 오래된 대기 시간, 전달 실패 횟수, 중복 소비율을 봅니다. 단순 큐 길이가 작아도 오래 멈춘 이벤트 하나가 고객 경험을 해칠 수 있습니다. 업무 우선순위별 지연 기준을 합의합니다.

복구 절차를 유지한다

아웃박스가 모든 분산 일관성을 해결하는 것은 아닙니다. 후속 서비스가 처리에 실패할 수 있고 순서가 바뀔 수도 있습니다. 보상 동작과 재처리 정책을 함께 설계해야 최종 상태가 기대와 맞습니다.

현장에 적용할 때의 순서

1. 업무 기록과 이벤트를 한 트랜잭션에 저장
2. 전달기·구독자 중복 처리 설계
3. 대기 시간과 미발행 건수 모니터링

주의할 실패: 아웃박스가 정확히 한 번 전달한다고 가정

관찰할 지표: 최장 대기·전송 실패·중복률

적용 전 체크리스트

• 업무 기록과 이벤트를 한 트랜잭션에 저장
• 전달기·구독자 중복 처리 설계
• 대기 시간과 미발행 건수 모니터링

참고 자료

Debezium — Outbox Event Router. 트랜잭션 아웃박스와 이벤트 라우팅 방식은 Debezium 공식 문서를 참고했습니다. 운영 지표와 보상 절차는 적용 제안입니다.

이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.

#아웃박스패턴 #이벤트발행 #트랜잭션 #데이터정합성 #분산시스템 #네이처프랙탈 #시스템설계 #서비스운영 #안정성 #데이터활용