수집 결과 전파 방식 (Kafka 이벤트 vs 동기 오케스트레이션)
상태
승인
후보군
| 방안 | 설명 |
|---|---|
| Kafka 이벤트 발행 | 수집 커밋 후 marketflow.collected.v1 발행, 소비자가 비동기로 재계산 |
| 동기 인프로세스 오케스트레이션 | 수집 배치가 끝나며 곧바로 재계산을 직접 호출 |
결정
수집 완료 후 marketflow.collected.v1(기준일) Kafka 이벤트를 발행한다. outbox는 두지 않고 커밋 후 직접 발행한다.
과거 결정 참조
- 메시지 소비 트레이스 검증 방식 선택 — Kafka는 인프라·OTel-poc 샘플만, 실도메인 적용은 보류 상태였음
결정 이유
- 소비자가 추천·포트폴리오·관심종목 3개다. 이벤트 fan-out으로 수집기가 소비자를 몰라도 되게 디커플링한다.
- Kafka를 이미 provision했고 도메인 적용을 미뤄둔 상태(ADR-007 옵저버빌리티)다. 첫 실도메인 이벤트로 자연스럽다.
- 향후 소비자 추가(알림·리포트 등)가 수집기 수정 없이 가능하다.
outbox 미도입
- 1일 1회·멱등·수동 재트리거가 가능해 발행 유실 시 복구가 쉽다. 발행 실패는 로그·알림으로 남긴다. 빈도·정합성 요구가 커지면 재검토한다.
검토 대안
| 방안 | 기각 이유 |
|---|---|
| 동기 오케스트레이션 | 디커플링·fan-out·확장성 상실. 1일 1회엔 단순하나 이벤트 도입 방향과 배치 |
| 트랜잭션 outbox | 1일 1회·멱등엔 과投資. 발행 유실은 수동 재트리거로 충분 |
트레이드 오프
| 구분 | 내용 |
|---|---|
| 득 | 디커플링·fan-out·확장성, Kafka 도입 방향 실현 |
| 실 | 커밋 후 발행 유실 가능성(수동 재트리거로 보완), 비동기 처리·DLQ 운영 추가 |