IOSOR 가이드
중복 웹훅은 두 번째 차감을 생성해서는 안 됩니다
장애 경로: 재시도와 재생은 선불 금액과 받은 편지함에서 멱등성을 유지합니다 — 하나의 이벤트 ID, 하나의 차감 행, 하나의 받은 편지함 줄.
최소 한 번 전달은 재시도를 수행합니다. 두 번째 차감이나 두 번째 받은 편지함 줄을 게시하는 중복 웹훅은 «무해한 ACK»가 아니라 금전 및 운영 사고입니다. 이 페이지는 장애 경로입니다. 재시도와 재생은 API 전송 멱등성 에세이나 인바운드 SMS 재시도 플레이북이 아니라, 선불 금액과 받은 편지함에서 멱등성을 유지합니다.
관련: 서명 및 리플레이 창 게이트, 첫 발송 전 웹훅 계약, 같은 장부의 차감 행과 전달 상태.
IOSOR은 화이트라벨 선불입니다. 20 USD로 단일 소비자에 대한 중복 이벤트 스모크 테스트를 자금 조달하고, 월 약 1,000 USD 근처의 소프트 검토는 «재시도 = 신규 청구»를 정산 부채로 가격 책정합니다. 고객은 화이트라벨 이벤트 ID만 볼 수 있습니다.
멱등성은 슬로건이 아니라 장애 경로입니다
해피 Path: 하나의 서명된 이벤트, 하나의 수락, 하나의 차감. 장애 경로는 신뢰를 태웁니다 — 타임아웃, 5xx, 제공업체 재생, 운영자 재푸시. 부작용(장부, 받은 편지함, CRM) 전에 첫 발송 전 웹훅 계약의 멱등성 키를 저장하십시오. 부드러운 월 1,000 USD는 «ACK 후 새 키 발명»을 볼륨 부채로 취급하며, 20 USD는 강제 재생이 절대 돈을 두 배로 만들지 않음을 증명합니다.
중복으로 간주되는 것
| 신호 | 중복으로 처리하는 조건 | 안전한 결과 |
|---|---|---|
| 이벤트 ID | 창 내에서 이미 수락된 동일한 ID | ACK; 두 번째 차감 없음 |
| 메시지 ID | 장부에 이미 연결된 동일한 메시지 | 행 재사용; 신규 청구 없음 |
| 받은 편지함 키 | 이미 파일링된 동일한 MO/MT | 두 번째 받은 편지함 줄 없음 |
| 창 외 | 게이트 거부 후의 오래된 재시도 | 거부; 금액/상태 기록 없음 |
| 알 수 없는 유형 | 계약 이벤트 목록에 없음 | 삭제; 조작된 성공 없음 |
서명 및 리플레이 창 게이트가 진위 여부와 신선도를 결정합니다. 이 페이지는 유효한 중복 후에 발생하는 일을 소유합니다: 하나의 종료 상태, 하나의 금액 줄, 하나의 받은 편지함 줄.
돈이 두 번 이동해서는 안 됩니다
동일한 이벤트 ID에 대한 두 번째 차감은 제품이 «여전히 배송됨으로 표시»하더라도 버그입니다. 재무는 이벤트 또는 메시지 ID로 필터링하여 해당 UTC 창에 대해 하나의 선불 행을 확인합니다. ACK 후의 부분적인 부작용(CRM 먼저, 장부 나중)은 이중 진실을 만듭니다. 지속 후 처리가 실패하면 동일한 키로 작업자를 재시도하고, HTTP 본문을 새 청구로 다시 수락하지 마십시오. 중복 스모크가 하나의 장부 행을 표시할 때까지 소프트 볼륨 언어는 차단된 상태로 유지됩니다.
받은 편지함도 두 배가 되어설 안 됩니다
멱등성은 돈만을 위한 것이 아닙니다. 두 번째 받은 편지함 스레드를 여는 재생된 인바운드 또는 전달 이벤트는 지원팀이 유령을 쫓도록 훈련시키며 자동 응답 루프를 트리거할 수 있습니다. 차감에 사용된 것과 동일한 이벤트 ID로 받은 편지함 키를 저장하십시오. 제품과 재무는 거부/중복 용어를 공유합니다: 제품과 재무를 위한 공통 상태 언어. 20 USD는 하나의 강제 재생이 받은 편지함 카디널리티를 변경되지 않은 상태로 유지함을 증명합니다.
중복 안전 웹훅을 위한 구매자 체크리스트
- 계약에서 합의되고 부작용 전에 저장된 멱등성 키 모양?
- 창 내 중복 이벤트 ID → 두 번째 차감 없는 ACK?
- 동일한 메시지 ID가 두 번째 선불 장부 행을 열지 않는지?
- 동일한 방식으로 키가 지정된 받은 편지함 삽입 — 재생 시 두 번째 스레드 없음?
- 서명 실패 및 창 거부가 실제 중복과 별도로 카운트 가능한지?
- 중복 스모크가 빨간색인 동안 부드러운 월 1,000 USD 이야기가 차단되는지?
«아니오»가 있으면 중복 안전 웹훅 금액 — 그리고 신뢰할 수 있는 받은 편지함 — 이 초안 상태로 유지됩니다.
IOSOR로 시작하기
이미 청구된 경로에서 창 안에 서명된 webhook 을 한 번 강제 재전송한다. 이벤트 id 와 ledger id 를 나란히 내보내고 차변 한 줄과 수신함 한 줄만 증명한다. 두 번째 차변이 보이면 그 소비자를 멈추고 여분 줄을 환급한다. 뒤 트래픽으로 상계하지 마라. 이것은 재전송 돈 문이지, E.164 문법 검사나 배송 문안이 아니다.
IOSOR 핵심 요약
재전송은 새 발송이 아니다. 이벤트 id 하나당 차변 하나.
할 일: 서명과 재전송 창을 켠 채, 창 안 POST 뒤에 차변 한 줄만 증명한다. 하지 말 일: POST 마다 차변하거나 네트워크 재시도를 두 번째 청구로 보지 마라.
이 가이드가 도움이 되었나요?
관련 가이드
- Webhook 엔드포인트 상태 지표 모니터링
IOSOR 플랫폼 내에서 수신 응답 지연 시간과 상태 코드를 추적하여 Webhook 상태를 사전에 관리하고 콜백 실패를 방지하는 방법을 알아보세요.
- 선불 잔액 임계값 웹훅 알림 구성
IOSOR에서 자동 잔액 임계값 웹훅을 구성하여 선불 계정을 모니터링하고, 서비스 중단을 방지하며, JIT 번호 프로비저닝을 효과적으로 관리하는 방법을 알아보세요.
- Just-in-Time 프로비저닝 웹훅 이벤트 처리
IOSOR JIT 프로비저닝 웹훅을 사용하여 인바운드 채널의 실시간 수명 주기를 마스터하세요. 화이트 라벨 CPaaS를 위한 번호 할당 및 장부 업데이트를 자동화합니다.