두 가지를 한 호출 하나

주문을 수집해서 처리하는 배치를 만들고 있었다. 수집과 발송 처리 사이에 간격이 있는 흐름이다.

Open Table of contents

배경 — 수집과 처리 사이의 간격

흐름은 이렇다.

주문 수집 → (간격) → 발송 처리 호출

주문 수집 시점과 발송 처리 호출 시점이 다르다.

배치라서 그 사이가 수십 분이 될 수 있다. 그 간격 동안 주문 쪽에서 무슨 일이 일어나는지는 우리가 모른다.

질의응답을 뒤지다 걸린 것이 있었다. 취소 요청 상태인 주문에 발송 처리를 부르면 이렇게 된다.

발송 처리
+ 구매자의 취소 요청 철회

발송 처리 만 되는 것이 아니라 취소 요청 철회 가 함께 실행된다.

우리 배치에 대입하면 이런 순서가 나온다.

10:00  주문 수집 — 취소 요청 없음
10:05  구매자가 취소 요청
10:30  발송 처리 호출
         ↓
       취소 요청이 자동 철회됨
       상품이 실제 출고됨

10:05 에 취소했는데 물건이 나가고 그 취소는 기록에서 사라진다.

취소 철회 여부 를 끄는 옵션이 있는지 찾았지만 없었다. 공급자 답변은 이랬다.

현재 발송 처리 API에 취소 철회 여부를 설정하는 옵션을 제공하고 있지 않습니다.
... 그 간격이 매우 짧아 이슈가 발생할 가능성은 낮을 것으로 보입니다.

옵션을 제공하고 있지 않습니다 라는 말과 확률이 낮다는 말이 전부다.

여기서 확률이 낮다는 것은 조건이 붙은 말이다. 수집과 호출이 거의 붙어 있는 실시간 처리를 전제로 한 판단으로 읽힌다.

[실시간 처리]  간격 수 초
[배치]         간격 수십 분

우리 쪽은 배치 라서 같은 말을 그대로 받을 수 없었다.

왜 분리가 안 되는지에는 이유가 있었다.

판매자가 취소를 거부하는 수단이 애초에 이 경로로만 제공된다. 취소 거부 와 발송 처리 가 같은 호출인 셈이다.

그러면 분리는 구조적으로 불가능하다. 옵션을 안 만든 것이 아니라 두 동작이 하나로 설계돼 있어서 뗄 자리가 없다.

우리 쪽에서 할 수 있는 것은 호출을 안 하는 것뿐이고 그러려면 클레임 상태 를 미리 알아야 했다.

방어 수단이 하나 남아 있었다.

수집 → ... → [상태 재확인] → 발송 처리
                 ↑
            여기서 취소면 건너뜀

부르기 직전에 상태 재확인 을 넣고 취소 요청이 있으면 그 건은 건너뛴다.

이것도 틈은 남는다.

상태 재확인 (취소 없음)
    ↓ 이 사이
취소 요청 들어옴
    ↓
발송 처리 → 철회됨

상태 재확인 과 발송 처리 사이가 남고 그 간격이 짧아서 확률이 낮아질 뿐이다.

공급자가 말한 상황으로 돌아온 셈인데 그래도 넣는 쪽이 맞다고 봤다. 안 넣으면 수십 분 간격의 취소가 전부 철회되고 넣으면 수 초 간격의 취소만 위험해진다.

없앨 수는 없지만 위험 구간을 수십 분에서 수 초로 줄이는 것이 이 한 번의 조회가 하는 일이었다.

막지 못하는 위험이 남으면 그것이 일어났는지 알 수 있어야 한다.

상태 재확인 에서 취소 없음으로 판정한 시각과 그때의 대상 목록을 남기게 했다. 나중에 문의가 오면 그 시각과 취소가 들어온 시각을 대조할 수 있다.

기록이 없으면 부수 효과로 철회된 것인지 다른 이유인지 가릴 수 없고 구매자 문의로만 알게 된다. 막을 수 없는 위험은 최소한 사후에 식별할 수 있어야 했다.

이 건에서 남은 것은 형태 쪽이다. 호출 하나가 문서에 없는 부수 효과를 함께 실행한다는 형태를 알고 나면 클레임 과 배송을 함께 다루는 다른 자리도 의심하게 된다.

같은 질의응답에서 다른 제약도 함께 나왔다.

호출당 최대 30개 주문번호
분할 발송 미지원
이미 처리된 주문 재호출 시 특정 에러 코드

최대 30개 와 분할 발송 미지원 과 재호출 에러가 묶음 크기와 부분 발송과 중복 방지를 여기서 갈랐다. 만들다가 하나씩 만났으면 그때마다 앞으로 돌아가야 했을 것이다.