ACK 전에 꺼진 간식 자판기 · 저장된 주문과 사라진 전달 의도 · 퀴즈
퀴즈: 저장된 주문과 사라진 전달 의도
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
주문 커밋 뒤 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 커밋으로 합쳐진다
- 네트워크가 끊겨도 실제 요청은 반드시 한 번만 간다
- 전달 루프가 없어도 창고가 즉시 최신 상태가 된다