피드로 돌아가기
The Other Half of the Dual-Write Problem: What Happens When a Job Finishes
Dev.toDev.to
Backend

DB Transaction 통합으로 Dual-Write 문제와 Idempotency 오버헤드 완전 제거

The Other Half of the Dual-Write Problem: What Happens When a Job Finishes

Yury2026년 5월 19일10advanced

Context

작업 처리 결과 저장과 Queue의 완료 상태(ACK) 업데이트가 서로 다른 시스템 혹은 트랜잭션으로 처리되는 Dual-Write 문제 분석. 작업 완료 후 ACK 전송 전 시스템 장애 발생 시, DB에는 결과가 반영되었으나 Queue는 미완료 상태로 인식하여 동일 작업이 중복 실행되는 구조적 한계 존재.

Technical Solution

  • Job Table을 비즈니스 데이터와 동일한 Database 내에 배치하여 단일 트랜잭션 범위 확보
  • Atomic Mode를 통한 비즈니스 로직 수행, 결과 저장, Job 완료 처리를 하나의 Commit으로 묶는 구조 설계
  • Staged Mode 도입으로 외부 API 호출과 결과 기록 단계를 분리하여 외부 시스템의 Idempotency 의존성 최소화
  • 별도의 Outbox Table이나 외부 오케스트레이터 없이 DB 자체의 원자성을 활용한 상태 동기화 구현
  • Queue Library의 추상화된 Worker 루프 대신 DB Transaction-fused-with-completion Flow를 API 기본값으로 설정

1. Job Queue의 상태 저장소가 비즈니스 DB와 분리되어 있는지 확인

2. 작업 완료 후 ACK 전송 실패 시 재시도 로직이 비즈니스 데이터 중복 생성을 유발하는지 검토

3. 모든 핸들러에 Idempotency 로직이 과도하게 중복 구현되어 있다면 DB 기반 Queue 전환 고려

4. 외부 시스템 호출이 포함된 작업의 경우, 호출 결과 기록과 Job 완료 처리가 단일 트랜잭션으로 묶여 있는지 확인

원문 읽기