pandaterry's 개발로그

이전 글(https://pandaterry.tistory.com/10)에서는 Redis AOF, RDB과 Kafka를 비교하며 메시지 유실 문제를 직접 실험했습니다. AOF(Append Only File)와 RDB 설정을 활용해 Redis에 유실되지 않는 메시지 큐 구조를 흉내내는 실험을 진행했었고,단순 큐잉 수준에서는 Redis로도 Kafka의 일부 역할을 대체할 수 있다는 가능성을 확인했습니다. 하지만 여전히 해결되지 않은 문제가 있었습니다. Kafka가 주목받는 진짜 이유는 ‘복구’와 ‘재처리’에 있습니다. 단순히 메시지를 저장하는 것을 넘어서,누가 메시지를 소비했는지 추적하고실패한 메시지는 다시 재시도하거나결국에는 DLT(Dead Letter Topic)으로 보낼 수 있는 운영 가능한 복구 흐름..

이전 글(https://pandaterry.tistory.com/9)에서는 Redis Pub/Sub과 Kafka를 비교하며 메시지 유실·재처리 이슈를 검증했습니다. 이번 글에서는 “Redis만으로도 신뢰형 메시지 큐를 구현할 수 있지 않을까?”라는 의문으로 다음 방식으로 직접 비교·실험해보겠습니다. 왜 Pub/Sub만으로는 부족했을까?현재 개발중인 SaaS 서비스는 “사용자의 Saas 기능 사용 -> 사용량 측정”이라는 흐름을 비동기로 처리합니다. 이 구조에서 가장 먼저 선택한 메시지 브로커는 Redis Pub/Sub이었습니다. 설정이 간단하고, 즉각적인 전달이 가능했기 때문입니다.하지만 곧 문제를 마주하게 됩니다."만약 메시지를 구독 중이던 서버가 죽는다면?""그 사이에 발행된 메시지는 어떻게 되는가..