토픽 이름, payload, key가 변경 이력을 설명해야 합니다.
Kafka 도입은 토픽, 소비, 재처리 책임을 함께 정하는 일이다
NestJS는 Kafka transport를 쉽게 연결해주지만, 이벤트가 어떤 계약으로 오래 살아남을지는 애플리케이션이 정해야 합니다.
groupId로 작업 단위를 나누고, 장애가 다른 소비자에 번지지 않게 합니다.
retry, DLQ, idempotency가 있어야 재처리가 안전합니다.
| 책임 | 정할 기준 | 검증 신호 |
|---|---|---|
| 발행 | 언제 이벤트를 쓰고 어떤 payload를 담는가 | producer 로그와 topic offset 증가 |
| 소비 | 어떤 group이 어떤 부작업을 처리하는가 | consumer 로그와 처리 성공 기록 |
| 복구 | 실패 이벤트를 언제 재시도하고 언제 DLQ로 보내는가 | 재시도 횟수, DLQ 건수, 중복 처리 여부 |
정리: Kafka는 비동기 통신을 가능하게 하지만, 좋은 설계는 이벤트 이름보다 운영 중 다시 읽고 복구할 수 있는 계약에서 결정됩니다.