코드 저장소.

목차1. 도입 배경2. EOS(Exactly Once Semantics) 접근 방식3. 설계 및 구현 방법4. 후기 1. 도입 배경현재 서비스는 Outbox + DLQ + Retry 구조로 이벤트 발행 및 복원력을 확보하고 있습니다. 이 방식은 at-least-once 전달 보장을 만족하여 메시지 유실은 방지할 수 있습니다. Outbox로 DB 트랜잭션과 메시지 발행의 원자성을 맞췄고, DLQ/Retry를 통해 장애 상황에서도 재처리가 가능하기 때문에 안정적으로 이벤트를 보낼 수 있습니다. 하지만 여전히 한 가지 문제가 남아 있습니다. 메시지의 중복 처리입니다. 문제의 소지는 동일한 Outbox 이벤트가 재발행되었을 때 Retry 스케줄러가 같은 이벤트를 재전송했을 때 Consumer가 재시작되면서 of..

목차1.왜 DLQ를 적용했는가?2.프로젝트에 적용한 방식3.후기 1.왜 DLQ를 적용했는가?Kafka 기반의 알림 시스템을 운영하면서, 메시지 컨슈머에서 특정 상황에서 예외가 발생하는 문제를 마주했습니다. 예를 들어 DB 저장 실패, WebSocket 전송 실패, 직렬화 오류 등 다양한 이유로 Consumer에서 예외가 발생할 수 있습니다. Kafka에서는 기본적으로 Consumer가 예외를 던지면 해당 파티션의 메시지 소비가 멈춰버립니다. 이런 구조에서는 일시적인 오류 하나로 인해 전체 알림 시스템이 영향을 받을 수 있습니다. 이를 해결하기 위해 DLQ(Dead Letter Queue) 를 도입했습니다. DLQ는 실패한 메시지를 별도의 토픽으로 격리시켜 메시지 유실을 방지하고, 이후에 재처리 로..

목차1.기존의 코드의 문제점2.왜 Kafka를 사용을 했는가?3.적용4.후기 1.기존 코드의 문제점현재 일정관리프로젝트에서는 스프링 이벤트 드라이븐을 사용해서 단일 인메모리 이벤트 처리로 후처리를 하고 있지만 해당 방식에는 다음과 같은 문제가 있습니다. 비동기 처리라 해도 같은 서버 내에서만 작동→ 이벤트를 발행한 서버 내부에서만 처리되기 때문에 다중 인스턴스 환경에서는 서버 간 이벤트 공유가 어렵습니다. 서버 장애 시 이벤트 유실 가능성→ 스프링 이벤트는 영속성이 없어 처리 중 서버 장애가 발생하면 복구가 어렵습니다. 후처리 로직이 많아질수록 하나의 서비스에 부하 집중→ 알림, 추천, 로그 처리 로직이 계속 누적되면서 애플리케이션 책임이 커집니다. 서비스 간 확장 어려움→ 실제로 서비스 서버를 분산..