토픽 발행은 커밋 뒤 best-effort로 하고 전달 보장을 두지 않는다
맥락
토픽으로 나가는 것이 둘이다. DB를 바꾼 사실(회의 상태·전사 확정), 그리고 유실돼도 되는 실시간 표현 (partial, 챗 token). 성질이 다른 둘이 같은 채널을 쓰는데, 전달 보장을 어디까지 할지 정해야 했다.
결정
- DB 변경 이벤트는 커밋 뒤(AFTER_COMMIT), 스트림 이벤트는 즉시 발행한다.
- broker 발행 실패가 녹음·챗 원본 흐름을 중단시키지 않게 격리한다.
- 토픽은 영속 상태의 invalidate 신호일 뿐이다. 소비자는 재연결 시 REST를 다시 읽어 수렴한다. 이 전제 위에서만 전달 보장이 필요 없어진다.
- 되돌리는 조건을 기록한다 — "토픽 payload 자체가 유일한 상태원이 되거나 감사 가능한 전달 보장이 필요할 때".
대안
대안 1 — transactional outbox + 재전송 가능한 event log. 감사 가능한 전달 보장을 얻고 유실을 탐지할 수 있다. 기각한 이유: partial·token은 유실돼도 되는 실시간 표현이라 outbox 비용과 맞지 않는다. 초대 계열에서도 같은 이유로 outbox 계획이 폐기됐다.
대안 2 — 트랜잭션 안에서 발행. 커밋과 발행이 원자적으로 묶인다. 기각한 이유: 커밋되지 않은 상태를 남에게 보여 주게 된다.
결과
- 유실 가능한 실시간 표현에 outbox 비용을 붙이지 않는다.
- 늦게 도착한 이벤트도 payload를 쓰지 않고 REST를 다시 읽으면 현재 서버 상태로 안전하게 수렴한다. 이 원칙은 APP-288에서 다시 쓰였다.
- 이벤트가 유실돼도 알 방법이 없다. 발행 실패는 원본 흐름과 격리돼 조용히 지나간다. 감사 가능한 전달 보장은 어디에도 없다.
- 커밋 뒤 발행이라 커밋과 발행 사이에 프로세스가 죽으면 그 이벤트는 영영 안 나간다.
- 모든 소비자가 "이벤트를 받으면 REST를 다시 읽는다"를 지켜야 한다. payload를 상태원으로 쓰는 소비자가 하나라도 생기면 이 전제가 깨진다.