Redis Streams vs Pub/Sub: 저장형 알림 설계, 무엇을 써야 할까?

1. 문제 정의

마이크로서비스가 늘어나면서 알림 메시지를 “한 번만, 정확히” 보내는 일이 점점 까다로워졌습니다. 실시간성이 중요하지만, 장애 · 스케일아웃 상황에서도 메시지 유실 없이 다시 처리할 수 있어야 하죠. Redis에는 두 가지 선택지가 있습니다.

---

2. Redis Pub/Sub ― “속도 우선”

• 휘발성(Volatile): 구독자가 없으면 메시지는 즉시 사라집니다. 실시간 채팅·라이브 지표처럼 “지금 안 보면 무의미”한 트래픽에 적합합니다.
• 팬아웃 구조: 하나의 publish 로 모든 인스턴스가 동시에 수신 → 코드가 단순, 지연 < 1 ms.
• 주요 최신 기능: Redis 7.2 ‘Sharded Pub/Sub’로 클러스터 확장 시 레이턴시와 CPU 부하가 줄었습니다.
• 단점: 장애 복구나 재전송이 필요하면 애플리케이션이 별도 DB · 로그로 상태를 저장해야 합니다.

---

3. Redis Streams ― “저장형 메시지”

• 로그 기반 저장: 메시지가 스트림에 append–only 형태로 남아 장애 후 재처리·리플레이가 가능합니다.
• Consumer Group: 각 메시지는 구독자 그룹 내에서 딱 한 번만 전달되고, ACK 전까지 ‘Pending’ 큐에 머뭅니다. 
• Back-pressure 처리: 읽지 못한 메시지가 쌓여도 손실 없이 순서대로 처리.
• 코드 복잡도: XREADGROUP, PEL(대기 목록) 관리, 재전송 로직이 필요해 Pub/Sub보다 난도가 높습니다.

---

4. 선택 가이드

1. “한 번만 전송” + “장애 복구” → Streams
2. “즉시 소비” + “지연 최소화” → Pub/Sub
3. 혼합 설계: 실시간 Push 는 Pub/Sub, 중요 이벤트 로그는 Streams 로 이중화하는 하이브리드가 실무에서 많이 쓰입니다.

---

5. 설계 팁

• 채널/스트림 네이밍: user:{id} 같이 개인 단위로 쪼개면 보안·필터링이 쉬워집니다.
• ACK 전략: Streams는 ACK 누락 시 XPENDING + XCLAIM 으로 자동 재배정 로직을 구현해 주세요.
• 모니터링: Pub/Sub은 INFO pubsub, Streams는 XINFO CONSUMERS 로 지표를 수집해 Grafana 대시보드에 올리면 병목을 빠르게 찾을 수 있습니다.

---

6. 결론

• Pub/Sub: “실시간, 유실 허용” → 가장 빠르고 단순한 알림 채널
• Streams: “저장·재처리 중요” → Durable Queue 역할까지 담당
  업무 특성과 장애 허용 범위를 먼저 정의하고, 필요하면 두 기술을 조합해 ‘속도와 안정성’을 모두 챙기세요.