웹훅: 반복, 지연 및 복구 처리

이 가이드가 달성하는 목표

• 알림 인증
• 영수증과 처리 분리
• 중복 영향 방지
• 차단된 이벤트 복구

빠른 확인

• 어떤 바이트가 서명되었습니까?
• 영수증은 언제 영구적입니까?
• 두 워커가 함께 작업할 수 있습니까?
• 공급자가 순서를 보장합니까?
• 손실된 이벤트를 어떻게 찾습니까?

단계별 방법

1. 1

   공급자 계약 읽기

   유형, 버전, 계정 컨텍스트, 서명, 타이밍 및 재시도 규칙 기록. Stripe는 전달 순서가 보장되지 않으며 중복이 발생할 수 있다고 명시합니다. 모든 API에 Stripe 관련 지연을 적용하지 마십시오.

   제공물: 날짜가 포함된 공급자 계약.

2. 2

   효과 발생 전 유효성 검사

   공급자가 요구하는 라이브러리 및 원시 본문을 사용하여 서명을 확인합니다. 허용되는 크기와 유형을 제한합니다. 비밀 키를 로깅하지 않고 승인된 환경에서 유효하지 않은 서명과 예상치 못한 계정 컨텍스트를 테스트합니다.

   결과물: 영향 없는 거부.

3. 3

   승인 전에 데이터를 보존합니다.

   내구성 있는 수신과 느린 처리를 분리합니다. 큐가 이벤트를 수락할 수 없는 경우 보존된 것으로 보고하지 않습니다. 성공은 계약에 따른 수신을 의미하며, 비즈니스 작업 완료를 반드시 의미하는 것은 아닙니다.

   결과물: 수신됨, 처리 중, 완료됨 및 차단됨 상태.

4. 4

   멱등성을 적용합니다.

   이벤트 키와 비즈니스 효과의 동일성을 정의합니다. 순차적 전달뿐 아니라 동시 반복을 테스트합니다. 원자적 제약 조건이나 잠금 없이 사전 검사를 수행하면 두 작업자가 동일한 효과를 생성할 수 있습니다.

   결과물: 효과 고유성 증거.

5. 5

   지연 및 무질서 처리.

   이전 알림이 현재 상태를 설명한다고 가정하지 않습니다. 계약에서 허용하는 경우 소스를 참조하고 검증된 비즈니스 전환을 적용합니다. 아직 해석할 수 없는 이벤트를 보존합니다.

   산출물: 전환 및 역순 테스트

6. 6

   조정 및 재실행

   소유자, 원인, 시도 횟수 및 종료 시점을 포함하는 오류 큐 준비. 재실행 중 중복 방지 유지. 공급자와 애플리케이션을 주기적으로 비교: 복구 성공이 이벤트 누락이 없음을 증명하는 것은 아님.

   산출물: 복구 절차 및 불일치 보고서

재사용 가능한 워크시트

승인된 의견을 기입하십시오. 이 항목들은 작업 템플릿이며, 관찰된 결과가 아닙니다.

메커니즘 구분

관리 지표

일반적인 실수

• 서명된 본문 검증 전 구문 분석
• 영구 수신 전 승인
• 순차적 전달 가정
• 중복 항목은 순차적으로만 테스트