LabHub
배우기 러닝패스 코스

ACK 전에 꺼진 간식 자판기 · 저장된 주문과 사라진 전달 의도 · 퀴즈

퀴즈: 저장된 주문과 사라진 전달 의도

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

    1. 원래 HTTP 연결을 자동 복구해 나머지를 보낸다
    2. 창고의 미완료 재고를 접수 DB가 자동 롤백한다
    3. 미완료 의도를 다시 읽어 같은 업무를 전송한다
    4. 커밋을 취소하고 주문 ID를 새로 발급해야 한다
  2. HTTP부터 성공시키고 주문 DB를 나중에 커밋하면 어떤 불일치가 가능한가?

    1. 창고에는 반영됐지만 주문 DB에는 없을 수 있다
    2. HTTP 성공이 주문 DB의 커밋도 함께 확정한다
    3. DB 커밋 실패가 창고의 효과를 자동으로 취소한다
    4. 요청 순서를 바꾸면 중간 장애 구간이 사라진다
  3. orders 삽입 뒤 outbox 삽입 전에 정리 코드 없이 종료했다. 같은 트랜잭션의 기대 상태는?

    1. orders만 한 행이고 다음 접수 때 outbox가 채워진다
    2. outbox만 한 행이고 orders는 창고가 복원한다
    3. 두 행이 남으며 미완료 표시만 사라질 수 있다
    4. 독립 연결에서 두 테이블 모두 새 행이 없다
  4. 같은 7개 주문을 타임아웃 뒤 재전송할 때 ID를 매번 새로 만들면?

    1. 새 ID의 접두어가 같으면 자동으로 중복이 된다
    2. 같은 의도가 별개 업무로 접수될 수 있다
    3. 내용이 같으므로 네트워크가 한 요청을 제거한다
    4. 이전 ID의 outbox가 새 ID로 자동 변경된다
  5. 전달 루프가 HTTP 응답을 기다리는 동안 source 쓰기 트랜잭션을 계속 잡으면?

    1. 두 DB가 같은 잠금을 공유해 원자성이 확장된다
    2. 수신 측 중복 검사가 필요 없어져 처리량이 오른다
    3. 외부 지연이 새 주문의 DB 쓰기까지 막을 수 있다
    4. 네트워크 타임아웃이 source 커밋을 대신 완료한다
  6. outbox 패턴만 도입했을 때 직접 주장할 수 있는 개선은?

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