# Outbox Pattern
Transactional Outbox Pattern 알아보기
TL;DR 메시지를 DB 트랜잭션과 묶어서 커밋하여 비동기적으로 메시지 브로커에게 전달하는 패턴 Overview 이벤트로 기반으로 분리된 분산환경에서 우리는 특정 DB 상태를 변경하는 트랜잭션과 함께 이벤트를 발행해야할 때가 있습니다. 가령 웹 서비스에 회원 탈퇴 요청이 왔을 때 회원의 탈퇴가 발생했다는 이벤트를 발행시켜 해당 메시지를 구독하는 서비스들에게 회원 탈퇴 이벤트를 전달하는 경우입니다. 회원 탈퇴 이벤트를 구독하는 서비스들은 탈퇴된 회원에게 메일을 보낸다던지, 적재된 회원의 개인정보를 삭제하는 로직을 진행시킨다던지, 회원이 작성한 게시글을 비공개를 돌린다던지 목표하는 비즈니스 로직을 진행시킵니다. 하지만 이벤트로 분리된 애플리케이션 환경에서는 고민해야할 문제가
[3편] MSA 이벤트 발행 - Debezium Transformations
이전글 > [2편] MSA 이벤트 발행 - 구현 > Outbox 패턴을 적용하여 비지니스 객체 변경과 이벤트 발행이 하나의 트랜잭션으로 동작하는 강의 서비스 애플리케이션을 구현했다. 지난 글에서 debezium을 이용하여 OUTBOX에 쓴 메시지를 kafka 메시지 브로커로 발행하는 방법에 대해 알아봤다. 하지만 강의를 게시하는 하나의 트랜잭션에 메시지가 다음가 같이 3개가 발생한다. 그 이유는 애플리케이션에서 이벤트 발생 시 outbox에 이벤트를 쓰고 지운다. 이에 따라 위와 같이 create 메시지와 delete 메시지가 발생한 것이다. 하지만 우리는 강의를 게시하는 하나의 트랜잭션에 하나의 메시지만 생성하면 된다. 그 중 첫번째 메시지를 beautify 한
[2편] MSA 이벤트 발행 - 구현
* 이전 글 * > [1편] MSA 이벤트 발행 - 이론 > MSA에서 비지니스 객체의 변경에 대한 이벤트를 발행할 때, 비지니스 객체 변경과 이벤트 발행이 하나의 트랜잭션으로 실행되어야하는 이유를 설명했다. 또한 이를 위한 방법으로 Outbox 패턴을 소개했다. [그림] 강의 서비스 아키텍처 - 강의 게시 요청 상세 위 아키텍처 그림은 강사(Teacher)가 강의 게시 요
[1편] MSA 이벤트 발행 - 이론
왜 이벤트를 발행해야 하나? MSA의 특징중에 하나는 Database per Service이다. 즉, 서비스 각각이 자체 DB를 가지고 있다는 것이다. 이를 통해, 서비스들은 서로 느슨한 결합을 유지할 수 있게 된다. 또한 다른 서비스가 DB 락을 획득하여 서비스를 블로킹하는 일을 방지할 수도 있다. 하지만 서비스 별로 DB를 가지고 있다보니 트랜잭션 관리나 반정규화된 데이터들의 동기 처리가 어렵다. 따라서 MSA에서는 최종 일관성을 보장하는 방법을 택하게 된다. > * 최종 일관성 (Eventual Consistency) * 이란? > 데이터 항목에 새로운 업데이트가 없으면 궁극적으로 해당 항목에 대한 모든 접근들은 마지막으로 업데이트된 값을 반환하는 것 > 즉, 일시적으로 데이터의 합이 맞지 않을 수 있지만, 언젠가 동기화가 되면 모든 클라이언트가 동일한 데이터를 받을 수 있게 된는 것이다. 그렇다면 어떻게 최종 일관성을 보장할 수 있을까? MSA에서는 어떤 서비스에