確認問題：注文は保存されたのに送信予定が消えた

주문 커밋 뒤 HTTP 전송 전에 프로세스가 끝났다. outbox가 같은 트랜잭션에 있었다면?

• 원래 HTTP 연결을 자동 복구해 나머지를 보낸다
• 창고의 미완료 재고를 접수 DB가 자동 롤백한다
• 미완료 의도를 다시 읽어 같은 업무를 전송한다
• 커밋을 취소하고 주문 ID를 새로 발급해야 한다

HTTP부터 성공시키고 주문 DB를 나중에 커밋하면 어떤 불일치가 가능한가?

• 창고에는 반영됐지만 주문 DB에는 없을 수 있다
• HTTP 성공이 주문 DB의 커밋도 함께 확정한다
• DB 커밋 실패가 창고의 효과를 자동으로 취소한다
• 요청 순서를 바꾸면 중간 장애 구간이 사라진다

orders 삽입 뒤 outbox 삽입 전에 정리 코드 없이 종료했다. 같은 트랜잭션의 기대 상태는?

• orders만 한 행이고 다음 접수 때 outbox가 채워진다
• outbox만 한 행이고 orders는 창고가 복원한다
• 두 행이 남으며 미완료 표시만 사라질 수 있다
• 독립 연결에서 두 테이블 모두 새 행이 없다

같은 7개 주문을 타임아웃 뒤 재전송할 때 ID를 매번 새로 만들면?

• 새 ID의 접두어가 같으면 자동으로 중복이 된다
• 같은 의도가 별개 업무로 접수될 수 있다
• 내용이 같으므로 네트워크가 한 요청을 제거한다
• 이전 ID의 outbox가 새 ID로 자동 변경된다

전달 루프가 HTTP 응답을 기다리는 동안 source 쓰기 트랜잭션을 계속 잡으면?

• 두 DB가 같은 잠금을 공유해 원자성이 확장된다
• 수신 측 중복 검사가 필요 없어져 처리량이 오른다
• 외부 지연이 새 주문의 DB 쓰기까지 막을 수 있다
• 네트워크 타임아웃이 source 커밋을 대신 완료한다

outbox 패턴만 도입했을 때 직접 주장할 수 있는 개선은?

• 로컬 업무와 전달 의도를 함께 남기는 경계가 생긴다
• 임의의 외부 결제도 하나의 DB 커밋으로 합쳐진다
• 네트워크가 끊겨도 실제 요청은 반드시 한 번만 간다
• 전달 루프가 없어도 창고가 즉시 최신 상태가 된다