상어코딩

설계 동기앞서 1편에서는 boolean 기반 sent 필드로 Kafka 전송 여부를 관리하는 기존 구조의 한계를 진단했습니다. 특히 다음 세 가지 문제를 해결하고자 리팩토링이 시작되었습니다:전송 결과의 모호함: 실패와 성공을 구분할 수 없음재시도 전략 부재: Kafka 전송 실패 시 복구 불가배치 최적화 미흡: Kafka로 단일 이벤트를 순차 처리 → TPS 병목설계 목표이번 개선의 핵심 목표는 다음과 같습니다.목표 항목개선 전개선 후상태 표현 방식boolean sentenum OutboxStatusKafka 전송 전략단일 전송배치 전송 + 상태 기반오류 처리실패 감지 불가실패 정보 저장 및 재시도 가능전송 주기없음스케줄러로 관리삭제 정책수동 삭제SENT + 시간 조건 기반 자동 삭제상태 모델링 - Ou..

도입서비스에 유저 활동 로그를 남기기로 결정한 이후, 나는 곧 중요한 딜레마에 부딪혔다. "유저 활동 로그는 쓰기 트래픽이 압도적으로 많고, 유실되어서는 안 되며, 속도도 중요하다." 이 세 가지 요구사항을 만족하기 위해 기존 Outbox 구조를 되돌아보게 되었다.기존의 Outbox는 단건 이벤트를 즉시 저장하고, Kafka로 전송하는 방식으로 구성되어 있었다. 하지만 로깅 시스템은 본질적으로 다르다. 수많은 작은 이벤트가 순식간에 쏟아지기 때문에, 기존 구조로는 병목이 생기고, 네트워크 사용량 또한 비효율적으로 늘어난다.기존 Outbox 구조의 한계초기 Outbox 구조는 단순하고 직관적이다.OutboxEventEntity에는 sent: boolean만 존재Kafka 전송은 개별 이벤트 단위상태 관리나..