0. TL;DR

사용자가 cloud 리소스를 사용하기 위해, 프로젝트를 신청하고, 이를 승인/거절 시에 비지니스 로직에 이어서 Discord, Email 알림이 전송됩니다.

여기서 알림 전송(Message Send)과 도메인 관련 트랜잭션(DB Update)을 원자적으로 처리해야 데이터 일관성이 보장되기 때문에 Transactional Outbox Pattern 을 사용하여 데이터 일관성을 보장하고자 합니다.

이런식으로 Outbox 저장 이후 메시지가 발행되지 않아도 Outbox 테이블에서 재발행이 가능하므로 알림 전송에서의 At-Least-Once를 보장하여 메시지의 유실을 방지할 수 있습니다.

또한, ApplicationEventPublisher을 통한 이벤트 기반 트랜잭션 처리를 통해, ****서로 다른 비지니스 로직 간의 강한 결합(강결합)을 완화하고 트랜잭션 처리 상의 문제를 해결합니다.

https://github.com/rlagnlfo1004/transaction-outbox-example


1. Transaction Outbox 패턴 도입 배경

현재 프로젝트 신청, 승인/거절시에 다음과 같은 작업이 이루어 집니다.

애플리케이션 로직상 트랜잭션이 완료되기 전에 이벤트 메시지를 발행합니다.

이때, 추후 비지니스 로직에서 예외가 발생하거나, DB에 쿼리를 날린 이후에 특정한 이유 때문에 예외가 발생해 롤백이 될 수 있습니다. 이 경우에 트랜잭션이 성공하지 않았는데 메시지가 발행이 되는 경우가 생길 수 있고 시스템의 안정성이 보장되지 못합니다.

Transactional Event

이 때 DB를 업데이트와 메시지 전송을 한 트랜잭션으로 묶지 않으면 문제가 발생합니다. 이 두 작업은 하나의 애플리케이션 서비스 내에서 원자적으로 수행되지 않으면 시스템이 실패할 경우 문제가 발생하게 되는 것입니다.