코드 저장소.

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

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

목차1.기존의 코드의 문제점2.왜 Kafka를 사용을 했는가?3.적용4.후기 1.기존 코드의 문제점현재 일정관리프로젝트에서는 스프링 이벤트 드라이븐을 사용해서 단일 인메모리 이벤트 처리로 후처리를 하고 있지만 해당 방식에는 다음과 같은 문제가 있습니다. 비동기 처리라 해도 같은 서버 내에서만 작동→ 서버가 죽거나 장애가 발생하면 스프링 이벤트는 영속성이 없어서 유실이 된다는 점입니다. 후처리 로직이 많아질수록 하나의 서비스에 부하 집중서비스 간 확장 어려움→ 향후 알림 시스템을 별도 분리하고자 할 때 제약이 됩니다. 결론적으로, 비동기 이벤트 처리의 영속성, 확장성, 결합도 측면에서 한계를 드러내기 시작했다.2.왜 Kafka를 사용을 했는가?카프카는 분산 메시징 시스템입니다. 물론 Kafka의 대안으로..