KAFKA OPERATIONS

lag가 쌓여도 같은 이벤트는 한 번만 반영되어야 한다

Kafka 안정성은 토픽 설계보다 재처리 경계에서 드러난다. event key, partition, handler, offset, DLQ를 한 흐름으로 확인한다.

판단 질문: consumer lag와 중복 이벤트가 생겨도 주문 상태가 같은 결과로 수렴하는가?

Event key eventId와 business key로 중복을 식별한다.

Partition 순서가 필요한 단위는 같은 key로 모은다.

Handler 상태 변경 전 멱등 키를 확인한다.

Offset 처리 성공 뒤 commit해 재처리 경계를 남긴다.

DLQ poison message는 payload와 실패 이유를 보존한다.

실패 형태	보이는 신호	고정할 기준
중복 소비	같은 eventId가 재시도 또는 rebalance 후 다시 들어온다.	멱등 키 저장 후 상태 변경을 한 번만 허용한다.
consumer lag	처리량보다 유입량이 많아 offset 차이가 커진다.	partition 수, consumer 수, 처리 시간을 지표로 본다.
poison message	특정 payload가 계속 실패해 queue를 막는다.	재시도 한계를 넘으면 DLQ로 이동시킨다.

테스트

중복 eventId, schema mismatch, handler 예외를 따로 재현한다.

로그

publish, consume, state update, commit을 같은 correlation id로 묶는다.

지표

consumer lag, DLQ count, 실패율을 배포 전후로 비교한다.