outbox를 발행할 때 테이블 polling과 CDC 중 무엇을 선택하고, 둘 다 필요한 중복 처리는 무엇인가요?

polling은 발행자가 outbox의 미처리 행을 조회하고 CDC는 DB 변경 로그를 통해 새 행을 읽습니다. 선택은 지연·DB 부하·운영 도구·복구 위치에 달려 있으며 어느 방식도 소비자 외부 효과를 자동 한 번으로 만들지는 않습니다.

동작 원리와 전제

polling은 작은 구성에서 이해하기 쉽지만 조회 인덱스·배치·잠금·빈 조회 비용이 필요합니다. 발행 성공 후 처리 표시 전에 죽으면 중복 발행할 수 있습니다. 여러 발행자는 행 획득과 소유권을 조정하고 순서가 필요한 aggregate는 별도 순서를 유지합니다.

선택과 실패 처리

CDC는 매번 미처리 행을 찾는 부담을 줄일 수 있지만 connector·로그 보존·스키마 변경·초기 snapshot을 관리해야 합니다. 이벤트 ID와 payload 버전은 두 방식 모두 안정적으로 유지합니다. 발행 위치와 실제 소비 적용 위치를 하나의 완료 상태로 합치지 않습니다.

구체적인 사례와 검증

발행자는 이벤트를 broker에 저장하고 ACK를 받은 뒤 outbox의 전송 상태를 바꿀 수 있습니다. 이 두 저장소는 원자적이지 않아 ACK 후 중단되면 같은 이벤트가 다시 발행됩니다. CDC를 쓰면 이런 애플리케이션 polling 표시는 없어질 수 있지만 connector의 offset과 sink 기록 사이 계약을 확인해야 합니다. 둘 중 어떤 방식을 택해도 안정적인 event ID가 downstream의 중복 방지 기준이 됩니다. outbox 행에 이벤트를 만들 당시의 payload를 저장할지 나중에 현재 주문을 조회해 만들지 정합니다. 후자는 재발행 시 내용이 달라질 수 있어 원래 사건의 재현성과 충돌합니다.

DB commit 직후 중단, 발행 ACK 유실, 발행 표시 실패, connector 재시작과 재생을 시험합니다. outbox 청소는 재처리·감사 보존과 합의하고, 표시 순서만으로 모든 키의 최종 적용 순서가 보장된다고 하지 않습니다. 운영 가능한 복구 경로가 있는 쪽을 선택하겠습니다.