[10장] 알림 시스템 설계 - 도선빈

[typingmistake]

📘 어떤 챕터를 읽었나요?

[10장] 알림 시스템 설계

❓ 궁금한 점 또는 이해 안 되는 부분

• 같은 알림이 여러 번 반복되는 것을 완전히 막는 것이 불가능한 이유가 뭘까요? 중복이 필연적이라면, 어떤 단계에서 중복이 발생하는 걸까요?
• 알림 시스템이 여지껏 나왔던 시스템 설계 중에서 가장 다양하고 많은 종류의 캐시 계층을 사용하는 것 같은데, 캐시 읽기-쓰기 전략은 어떤 것을 채택하는 것이 좋고, 또 그 근거는 무엇을 들 수 있을까요?

[Huiyeongkim]

1-1. 같은 알림이 여러 번 반복되는 것을 완전히 막기 어려운 이유는 결국은 분산 시스템이기 때문에 상태 일관성을 완벽히 보장하는 것이 어려울 것이라고 예상됩니다.
1-2. 중복은 여러 단계에서 일어날 것으로 예상합니다. 이벤트 자체에서도 중복이 일어날 수 있고, 큐나 DB 그리고 푸시 단계에서도 가능할 것이라고 생각합니다.
질문으로 이러한 중복을 줄이는 방법은 어떤 것이 있을까요? @typingmistake

2. 실무에서 알림 시스템은 Cache Aside + Write Through 조합을 많이 쓴다고 합니다.
   알림 읽기(조회) → Cache Aside로 빠른 조회
   알림 쓰기 → DB + 캐시 동시에 갱신 → 최신 알림 보장
   Write Behind는 DB 반영 지연으로 중복/누락 가능성 있어 실시간 알림에는 잘 안 씀

[typingmistake]

중복을 줄이는 방법은 책에 나와 있는 것처럼 JOB ID 기반으로 작업의 식별자를 부여하는 방법이 있습니다.
구체적으로는 요청이 들어왔을 때 요청에 대해 고유한 JOB ID를 생성하고(알림 내용+메타데이터의 해시값이면 충분히 중복을 줄일 수 있을 것 같습니다), 메세지 큐에 알림을 넣기 전에 중복을 검사하면 될 것 같습니다.
@Huiyeongkim