수신과 처리 완료 구분하기
보장은 제공자에 따라 다릅니다. Stripe는 중복 가능성과 순서 미보장을 문서화합니다. HTTP 성공 응답은 단순한 메모리 도착이 아니라 영속 수신이나 예정한 처리에 대응해야 합니다.
| 상황 | 예상 동작 | 유용한 증거 |
|---|---|---|
| 같은 이벤트 두 번 수신 | 중복 업무 효과 방지. | 처리 ID와 영속 결과. |
| 오래된 이벤트 나중 도착 | 새 상태를 무조건 덮어쓰지 않음. | 권위 있는 상태와 전이 규칙. |
| 무거운 처리 | 영속 수신 뒤 지연 작업. | 큐 상태와 워커 결과. |
| 전달 누락 | 제공자 규칙에 따라 대조 및 복구. | 확인한 차이와 검증한 수정. |
검증 가능한 수신 만들기
- 제공자 프로토콜에 따라 HTTPS, 서명과 재전송 방지를 확인합니다. Stripe는 원시 본문으로 서명을 검증하므로 먼저 JSON을 변환하면 검증이 실패할 수 있습니다.
- 적절한 수신 확인 전에 이벤트나 처리 기록을 영속 저장합니다. 전달 ID, 이벤트 ID와 업무 작업의 멱등 키를 구분합니다.
- 중복, 순서 변경, 워커 중단과 재시작을 테스트합니다. 오래된 이벤트로 안전하게 판단할 수 없으면 객체의 권위 있는 상태를 조회합니다.
복구와 대조 계획하기
시도, 기한, 미처리 이벤트와 제공자 대조 절차를 문서화합니다. 빠른 수신 확인이 이후 실패를 숨길 수 있습니다. 최종 업무 작업도 추적하고 로그의 비밀과 개인정보를 제한합니다.
1차 자료
반복되는 웹훅을 안전하게 처리합니다.
타임아웃 또는 응답 손실 후 알림이 반복될 수 있습니다. 신뢰성은 출처 확인, 이벤트 식별자 및 새 메시지와 중복 메시지를 구분하는 처리에 따라 달라집니다.
- 공급자 메커니즘을 사용하여 각 요청을 확인합니다.
- 재시도, 중복 및 변경된 도착 순서를 테스트합니다.
- 처리 후 또는 영구 큐잉 후 일관되게 확인을 보냅니다.
1차 자료: IETF RFC 9457 — Problem Details for HTTP APIs. 관련 방법: 실무 가이드 읽기.