Transactional Outbox 패턴

Transactional Outbox:

Message broker에게 메세지를 주는 대신, DB에 Outbox table을 두고 여기에 새 record로써 메세지를 추가하게 됨
(중요 사항: 이 작업은 단일 데이터베이스 트랜잭션에서 수행됨 -> atomicity가 보장됨)

이 후, Message Relay라는 서비스를 둠. 이 서비스는 Outbox table에 record가 추가됐을 경우, 이를 가져와서 Message broker에게 전송한 후, table에서 해당 record를 삭제함

이 패턴의 문제점

• 이벤트 중복의 가능성: Message Relay(Sender)가 Outbox table에서 추가된 record 형태의 메세지를 읽고 이를 Message broker에 보낸 상태에서, record를 삭제하기 전에 재시작된다면 다시 record를 Message broker에 보낼 수 있고, 이는 이벤트의 중복이 됨 (At Least Once Delivery Semantics)

  	-> Message Broker 이후 Scheduling Service를 통해 멱등 조작을 실현하면 됨
  	-> record 마다 고유한 id를 통해 중복 여부를 검사함

  
  

• 이벤트 순서 문제: 이벤트의 순서가 중요할 수 있다. 비즈니스 로직에 따라 순서대로 이벤트를 처리할 수 있게 해야함 (ex: 회원가입 후 회원 탈퇴 순서에서, 탈퇴부터 처리하고 가입시키면? 요구와 다르다.)

  	-> 시퀀스 id를 record에 부여하고, 이 순서대로 해결