컬리, 아웃박스 패턴과 재시도 토픽으로 입고 데이터 동기화 문제 해결!

간편한 설정: build.gradle에 의존성을 추가하고, application.yml에 아웃박스 관련 설정을 추가하는 것만으로 아웃박스 패턴을 적용할 수 있다.

자동화된 기능: 아웃박스 테이블 관리, 폴링(Polling) 스케줄링, 재시도 횟수/상태 관리 등을 자동화하여 개발자가 직접 구현해야 하는 부분을 최소화했다.

테이블 생성: DDL 권한이 없는 환경을 고려하여, 아웃박스 테이블을 수동으로 생성하는 방법을 제공한다.

자동 재시도(Automatic Retry): 메시지 처리 실패 시, 설정된 간격(10분)으로 최대 144회까지 재시도를 수행하여 일시적인 오류로 인한 메시지 유실을 방지한다.

데드 레터 큐(Dead Letter Queue, DLT) 처리: 재시도 횟수를 모두 소진한 메시지는 DLT로 전송하여, 관리자가 문제 발생 원인을 파악하고 수동으로 처리할 수 있도록 한다.

Spring Kafka RetryableTopic: 기존 컨슈머 로직에 어노테이션(@RetryableTopic)을 추가하는 것만으로 재시도 토픽을 구성할 수 있어, 구현의 편의성을 높였다.

아웃박스 패턴: DB 쓰기와 메시지 발행의 원자성을 보장하여 데이터 불일치 문제를 해결한다.

재시도 토픽: 메시지 처리 실패 시 자동 재시도를 통해 일시적인 오류를 극복하고, 데드 레터 큐(DLT)를 통해 문제 발생 시 관리자에게 알림을 제공한다.

결합 효과: 아웃박스 패턴은 메시지 발행의 신뢰성을 높이고, 재시도 토픽은 메시지 처리의 안정성을 높여, 전체 시스템의 데이터 동기화 프로세스를 견고하게 만든다.

책임 분리: 발행부는 아웃박스 패턴을 통해 메시지를 안전하게 내보내는 데 집중하고, 수신부는 수신된 메시지를 처리하며 자신의 재시도 상태를 스스로 관리하도록 설계했다.

직접 구현 vs 라이브러리 활용: 스케줄링 배치(Batch) 잡을 직접 작성하는 대신, 검증된 라이브러리(Namastack Outbox, Spring Kafka)를 활용하여 개발 생산성을 높였다.

3PL 사업의 본질적인 비즈니스 로직(Business Logic) 집중: 아키텍처 설계에 대한 고민을 통해, 3PL 사업의 핵심 가치에 집중할 수 있는 기반을 마련했다.