이벤트 전달, 멱등성 및 중복 처리
네트워크를 통해 이벤트를 보내면 프로듀서가 완벽하게 관찰할 수 없는 결과가 생성됩니다. 서버가 요청을 받기 전, 요청을 처리하는 동안 또는 이벤트를 수락한 후 응답이 호출자에게 도달하기 전에 시간 초과가 발생할 수 있습니다. 다시 시도하면 게재가 향상되지만 중복 행이 생성될 수도 있습니다.
부수적인 SDK 설정이 아닌 이벤트 계약의 일부로 배달 정책을 처리합니다.
모든 논리적 사건에 안정적인 정체성을 부여
신청 결과가 알려지면 event_id를 하나 생성하세요. 동일한 결과를 나타내는 모든 네트워크 시도에 해당 식별자를 재사용합니다. 재시도 루프 내에서 새 식별자를 생성하지 마세요.
const eventId = crypto.randomUUID();
const event = {
event_id: eventId,
job_id: job.id,
status: "failed",
error_type: "provider_timeout",
attempt: job.attempt,
};
await sendWithBoundedRetry("job_completed", event);
event_id를 사용하면 중복 항목을 감지할 수 있습니다. 저장소가 모든 중복을 거부한다고 보장하는 것은 아닙니다. 비즈니스 워크플로에 정확히 한 번만 효과가 필요한 경우 효과를 소유한 시스템에서 해당 요구 사항을 적용하세요. Telemetry는 결과를 설명해야 하며 지불, 자격 또는 데이터베이스 변형에 대한 거래 조정자가 되지 않아야 합니다.
재시도 가능한 실패 결정
연결 오류, 429, 502, 503 및 504와 같은 임시 용량 및 전송 오류를 다시 시도합니다. 응답이 제공되면 Retry-After를 존중하세요. 지터와 함께 지수 백오프를 사용하고 시도 횟수와 총 경과 시간을 모두 제한합니다.
변경되지 않은 400 요청을 재시도하지 마세요. 잘못된 JSON, 테이블 이름, 필드 유형 또는 스키마에는 프로듀서를 변경해야 합니다. 401 이후 누락되거나 취소된 자격 증명을 교체합니다. 403 이후에 필요한 범위의 키를 사용하세요.
속도 제한 및 API 오류 참조에는 응답 클래스와 재시도 규칙이 포함되어 있습니다.
기본적으로 중요한 경로에서 텔레메트리을 유지합니다.
일반적인 제품 및 운영 분석의 경우 일시적인 텔레메트리 오류로 인해 성공적인 고객 요청이 오류로 바뀌어서는 안 됩니다. 텔레메트리 시간 초과를 제한하고 안전한 진단 범주를 보고하고 제품의 오류 정책에 따라 계속합니다.
일부 워크플로에는 더 강력한 전달이 필요합니다.
- 청구 조정을 제공하는 사용 기록입니다.
- 승인된 통제에 필요한 보안 감사 이벤트.
- 다른 진실의 소스가 없어도 되돌릴 수 없는 비즈니스 결과.
이러한 경우 비즈니스 변경과 동일한 트랜잭션에서 내구성 있는 애플리케이션 소유의 아웃박스에 결과를 기록합니다. 작업자는 원래 event_id, 발생 시간 및 스키마 버전을 유지하면서 나중에 이벤트를 전달할 수 있습니다.
중복 및 누락된 배송 측정
중복 이벤트 ID SQL 레시피를 사용하여 두 개 이상의 저장된 행이 있는 식별자를 찾으세요. 수정 사항이 실제 전달 경로를 대상으로 하도록 중복 항목을 생성자, 릴리스 및 재시도 이유별로 분류합니다.
또한 모니터링:
- 프로듀서가 수락하고 거부한 이벤트 수
- 가장 오래된 배달되지 않은 아웃박스 기록의 기간
- 논리적 이벤트당 시도 횟수;
- 재시도 예산 이후 영구적인 실패;
occurred_at와timestamp_utc사이의 지연.
모든 쿼리를 중복 제거하면 손상된 프로듀서를 숨길 수 있습니다. 다운스트림 보고서가 event_id당 하나의 행을 선택하더라도 중복 비율 모니터링을 계속 표시합니다.
모호한 사례 테스트
성공, 확실한 거부, 전달 전 연결 실패, 서버가 이벤트를 수락한 후 시간 초과를 실행합니다. 재시도가 이벤트 ID를 재사용하고 애플리케이션 응답이 문서화된 실패 정책을 따르는지 확인하십시오.
이벤트 수집 문제 해결, 스키마 진화 및 텔레메트리 비용 관리를 계속 진행하세요.