설비 이벤트 재전송이 생산량을 두 번 세지 않게 하려면

설비 게이트웨이가 응답을 못 받으면 같은 생산 완료 이벤트를 다시 보낼 수 있습니다. 서버가 재전송을 새 실적으로 세면 생산량과 재고가 부풀어 오릅니다. 전송은 중복될 수 있다고 가정하고 집계가 한 번만 반영되게 해야 합니다.

이벤트의 정체성을 만든다

설비 ID와 발생 시각만으로는 같은 시각에 여러 개가 생길 수 있습니다. 원천에서 고유 이벤트 ID나 단조 증가 시퀀스를 부여하고, 재전송 때도 같은 ID를 유지합니다. 서버가 매번 새 ID를 만들면 중복 여부를 알 수 없습니다.

중복 여부를 확인한 뒤 카운터를 올리는 두 단계 사이에 동시 요청이 들어올 수 있습니다. 고유 제약이나 원자적 처리를 이용해 같은 ID는 한 번만 확정합니다. DB 저장은 됐지만 집계만 실패한 경우를 위한 재처리 절차도 설계합니다.

작업자가 수량을 바로잡는 행위는 같은 이벤트의 재전송이 아닙니다. 원본 이벤트를 참조하는 정정 이벤트나 새 버전으로 남기고, 이전 수치를 어떻게 조정할지 명시합니다. 기존 행을 조용히 덮어쓰면 감사 추적이 어려워집니다.

장비가 며칠 뒤 복구되면 오래된 이벤트가 들어올 수 있습니다. ID 보관 기간이 너무 짧으면 중복을 놓칩니다. 운영상 재전송 가능 기간과 기록 보존 비용을 비교하고, 기간 밖 이벤트는 별도 검수로 보냅니다.

원천 시퀀스, 수신 건수, 고유 저장 건수, 실제 생산량을 주기적으로 비교합니다. 특정 장비의 중복률이 높다면 네트워크나 확인 응답 설계가 문제일 수 있습니다. 중복 제거가 잘 된다고 원천 장애를 방치하지 않습니다.

주의할 실패: 수신 건수를 곧 생산량으로 합산

관찰할 지표: 중복률과 원천·집계 차이

Stripe Idempotent requests. 반복 요청을 중복 실행하지 않는 멱등성 원칙을 참고했습니다. 설비 이벤트 집계 방식은 글의 도메인 적용 예시입니다.

이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.

#이벤트중복 #멱등성 #제조데이터 #생산량집계 #설비연동 #재전송 #데이터정합성 #스마트팩토리 #이벤트소싱 #DB설계