주문 서비스에서 데이터베이스 커밋과 아파치 카프카 발행 사이에 서버 장애가 발생하면 메시지 유실이 일어날 수 있습니다. 이를 방지하기 위한 아키텍처 설계 방안이 논의됩니다.
면접 질문과 기존 방식의 한계
흔히 고려되는 해결책은 하나의 트랜잭션 안에서 메시지 전송 메서드를 함께 호출하는 것입니다.
그러나 이 방식은 카프카 발행이 데이터베이스 트랜잭션에 직접 참여하지 않아 원자성을 보장하지 못합니다. 커밋 직후 전송이 실패하면 메시지가 유실되며, 반대로 전송은 성공했으나 데이터베이스가 롤백될 경우에는 데이터베이스에 없는 이벤트가 카프카에 잔류하게 됩니다.
아키텍처 대안 비교: Outbox 패턴과 CDC
메시지 유실을 방지하기 위해 아웃박스 테이블 방식과 변경 데이터 캡처 방식이 대안으로 제시됩니다.
아웃박스 테이블 방식 아웃박스 테이블을 비즈니스 로직과 동일한 트랜잭션 내에 기록하면 발행 여부를 원자적으로 보장할 수 있습니다. 다만 폴링 퍼블리셔가 주기적으로 테이블을 조회해야 하며, 기본적으로 적어도 한 번 전달되므로 컨슈머 측의 멱등성 설계가 필요합니다.
변경 데이터 캡처 방식 별도의 변경 데이터 캡처 도구를 활용하면 폴링 오버헤드를 줄일 수 있습니다. 하지만 별도의 인프라스트럭처가 도입되며, 이 인프라가 단일 장애점이 될 수 있다는 점을 고려해야 합니다.
Outbox 테이블 멱등 키 설계
아웃박스 패턴을 실제로 구현할 때는 멱등 키를 어떻게 설계할 것인지에 대한 고민이 남습니다.
복합 프라이머리 키를 활용하는 방식과 별도의 고유 식별자 컬럼을 두는 방식 중 어떤 구조가 더 적절한지에 대해서는 상황에 따라 판단이 달라질 수 있으며, 최종적인 아키텍처 선택의 정답이 명시적으로 정해져 있지는 않습니다.