Kafka Message Queue Event Stream

Kafka Message Queue Event Stream 챕터는 Kafka를 단순 메시지 큐가 아니라 보관되는 event log로 보고, topic, partition, consumer group, offset을 처리 보장 관점에서 설계한다.
핵심은 producer key, partition 순서, consumer group 병렬성, offset commit, retry/DLQ, idempotent consumer가 한 흐름으로 맞물리는지 판단하는 것이다.
Java/Spring 백엔드 개발자는 DB commit, Kafka publish, listener 처리, ack, 재처리 로그를 연결해 데이터 지연, 중복, 누락을 설명할 수 있어야 한다.

Message Queue와 Event Stream 차이: queue는 작업을 나눠 처리하는 모델에 가깝고 stream은 보관되는 이벤트 로그에 가깝다. replay, retention, 여러 consumer group이 선택 기준이다.
Kafka Topic Partition Consumer Group: topic은 이벤트 종류, partition은 순서와 병렬성 단위, consumer group은 같은 목적의 소비자 묶음이다. partition key가 처리 순서와 skew를 만든다.
Ordering Offset Commit: Kafka의 순서는 partition 내부에서만 보장된다. offset commit은 처리 완료 선언이므로 DB 반영과 ack 순서가 장애 결과를 바꾼다.
Retry DLQ 중복 처리: retry는 일시 오류를 흡수하고 DLQ는 독성 메시지를 격리한다. 둘 다 consumer 멱등성과 재처리 절차 없이 신뢰성을 만들지 못한다.
Spring Kafka Producer Consumer: KafkaTemplate과 @KafkaListener는 입구일 뿐이다. key 선택, manual ack, error handler, DLT, 테스트가 운영 품질을 좌우한다.
이 챕터는 Web-Database의 단일 transaction/query 튜닝이 아니라, commit 이후 이벤트가 여러 소비자에게 늦거나 다시 도착하는 상황을 다룬다.

Kafka를 큐처럼만 보면 replay와 여러 consumer group의 의미를 놓친다.
- queue는 보통 작업을 한 소비자가 가져가 처리하는 모델이고, Kafka stream은 offset을 가진 소비자 묶음마다 같은 로그를 독립적으로 읽는다.
- 그래서 결제 처리 consumer와 추천 집계 consumer는 같은 topic을 다른 group으로 읽을 수 있다.
“Kafka는 순서를 보장한다”는 말은 절반만 맞다.
- 순서는 partition 안에서만 보장되며, topic 전체 순서를 원하면 병렬성을 거의 포기해야 한다.
- 주문별 순서가 필요하면 orderId, 사용자별 순서가 필요하면 userId처럼 순서 기준을 key로 선택해야 한다.
offset commit을 business commit과 같은 것으로 오해하기 쉽다.
- DB 저장 전에 offset을 commit하면 누락이 생길 수 있고, DB 저장 후 commit 전에 죽으면 중복이 생길 수 있다.
- 실무 설계는 중복을 받아들이고 idempotent consumer와 dedup key로 피해를 줄인다.

이 챕터의 핵심 판단 기준은 무엇인가?
- 어떤 event key로 partition 순서를 만들고, 어느 consumer group이 어떤 SLA로 읽으며, 실패 시 어느 offset과 business key부터 다시 처리할 수 있는지다.
Web-Database와의 경계는 무엇인가?
- Web-Database는 DB 내부 transaction과 query의 즉시 정합성을 다루고, 이 챕터는 DB commit 이후 이벤트 전달, replay, lag, consumer 멱등성을 다룬다.
개인 프로젝트에서 최소로 챙길 것은 무엇인가?
- topic/key 명세, consumer 처리 이력 테이블, manual ack 위치, retry/DLQ 로그, 같은 메시지 재전달 테스트다.

동블