Transactional Outbox Pattern

// 전형적인 위험 구조
@Transactional
public void process(Command cmd) {
    repository.save(entity);          // ① DB 저장
    eventPublisher.publish(event);    // ② 이벤트 발행 (별도 스레드/브로커)
}
// ①은 성공했지만 ②가 실패하면? → 데이터 불일치

[비즈니스 트랜잭션]
  ├── domain_table INSERT/UPDATE
  └── outbox_events INSERT  ← 같은 트랜잭션 (원자적 보장)

       커밋 후

[Poller / CDC]
  └── outbox_events PENDING 조회
      ├── 외부 API 호출 or 메시지 발행
      ├── 성공 → PROCESSED 표시
      └── 실패 → PENDING 유지 (retry_count++)

CREATE TABLE payment_outbox (
    id             BIGINT       PRIMARY KEY AUTO_INCREMENT,
    aggregate_id   VARCHAR(100) NOT NULL,          -- transactionNo 등
    event_type     VARCHAR(200) NOT NULL,          -- 'ApprovalRequested'
    payload        JSON         NOT NULL,
    status         VARCHAR(20)  DEFAULT 'PENDING', -- PENDING / PROCESSING / PROCESSED / FAILED
    retry_count    INT          DEFAULT 0,
    created_at     TIMESTAMP    NOT NULL,
    processed_at   TIMESTAMP
);

PENDING → PROCESSING (처리 시작 표시, 중복 처리 방지)
              ↓
      성공 → PROCESSED
      실패 → PENDING (retry_count++)
      스케줄러 크래시 → PROCESSING으로 stuck ← 안전장치 필요
              ↓
      N분 후 PROCESSING → PENDING 롤백 안전장치

retry_count > 5 → FAILED (알람 발송, 수동 처리)
FAILED 레코드 → Dead Letter 테이블 이관 or 알람

// module-scheduler (싱글 인스턴스에서 실행 → 중복 처리 없음)
@Scheduled(fixedDelay = 5000)
public void relay() {
    List<PaymentOutbox> pending = outboxRepository.findByStatus(PENDING, limit(100));
    for (PaymentOutbox outbox : pending) {
        outboxRepository.updateStatus(outbox.getId(), PROCESSING);
        try {
            externalApiClient.send(outbox.getPayload());
            outboxRepository.updateStatus(outbox.getId(), PROCESSED);
        } catch (Exception e) {
            outboxRepository.incrementRetry(outbox.getId());
        }
    }
}

DB outbox_events 변경 → Debezium CDC 감지
→ Kafka 토픽 (`payment.events`, `merchant.events`) 자동 발행
→ Consumer가 처리

트랜잭션 내
  ├── outbox INSERT (PENDING)        ← 안전망 기록
  └── Spring 이벤트 발행 (예약)      ← 즉시 처리 시도

커밋 후
  @Async 스레드
    성공 → outbox PROCESSED 표시
    실패 → outbox PENDING 유지

module-scheduler
    PENDING만 재처리 (유실/실패 건만)

"App이 QR 유효함을 확인했다" = "moretapay 승인 요청을 반드시 한 번 이상 실행해야 한다"
이 의도를 DB에 기록하는 것이 아웃박스의 역할

QR TTL = 66초
서버 재시작 시간 >> 66초 (현실적으로)

→ outbox 재처리 시 이미 만료
→ 사용자 결제 성공 불가
→ outbox의 가치 = 데이터 정합성 + 감사 추적 (성공률 향상 아님)