Kafka 이벤트 기반 아키텍처: consumer lag와 멱등성 점검

Kafka 안정성은 event key, partition, handler, offset, DLQ를 한 흐름으로 검증한다

lag가 낮아도 멱등성과 재처리 경계가 없으면 같은 이벤트가 상태를 두 번 바꾼다.

event key eventId와 business key로 중복 이벤트를 식별할 수 있게 만든다.

partition 순서 보장이 필요한 단위가 같은 partition에 모이는지 확인한다.

handler 상태 변경 전에 멱등성 키를 확인하고 성공 뒤 offset을 commit한다.

DLQ poison message는 원본 payload와 실패 이유를 보존해 재처리한다.

토픽과 파티션 키 계약

이벤트 순서가 필요한 엔티티는 같은 partition key를 쓰고 consumer group별 처리 책임을 분리합니다.

topic 계약

Producer/Consumer 처리 경계

NestJS ClientsModule producer, @MessagePattern consumer handler, schema registry, retry/DLQ 설정을 같은 이벤트 이름으로 연결합니다.

schema 계약

중복 소비와 poison message

같은 eventId가 두 번 들어와도 멱등 키로 상태 변경을 한 번만 허용하고 실패 메시지는 offset 처리와 DLQ로 분리합니다.

재시도와 멱등성

Consumer lag와 DLQ 증거

consumer lag, dead letter count, idempotency 테스트, schema 호환성 결과를 배포 전후로 비교합니다.

lag 증거

책임

토픽과 파티션 키는 순서 보장이 필요한 이벤트 단위로 고정 consumer group별 책임을 나누고 eventId나 business key로 idempotency 기준을 둡니다.

topic

경계

NestJS producer/consumer handler는 schema와 retry 정책을 함께 가진다 producer는 이벤트 이름과 payload version을 남기고 consumer는 처리 성공, 재시도, DLQ 이동을 같은 로그 키로 기록합니다.

retry

Lag/DLQ

consumer lag와 DLQ는 재처리 가능한 실패를 분리해 보여야 한다 poison message, schema mismatch, 중복 eventId를 따로 재현해 offset commit과 상태 변경이 엇갈리지 않는지 확인합니다.

DLQ

Kafka consumer lag와 멱등성 검증 지점

Ack와 offset commit publish, consume, 상태 업데이트, offset commit이 같은 eventId와 correlation id로 이어지는지 확인합니다.

Retry와 DLQ 분기 중복 이벤트, schema mismatch, poison message를 따로 재현하지 않으면 재처리 때 상태가 두 번 바뀔 수 있습니다.

Consumer lag 신호 consumer lag, DLQ count, idempotency 테스트 결과, schema registry 호환성 기록을 배포와 함께 남깁니다.

Kafka 운영 점검

질문: 중복 이벤트와 consumer lag가 생겨도 주문 상태가 한 번만 바뀌는가
순서: topic/partition key 계약 -> NestJS producer/consumer handler -> idempotency 테스트와 DLQ 재처리
위험: offset을 먼저 commit하거나 eventId를 저장하지 않으면 재시도 때 같은 이벤트가 두 번 반영됩니다.