Share
Sign In

알림 시스템

알림 유형

APNS

iOS의 알림 서비스로 device token과 payload를 정보로 보낸다.
# Payload { "apps": { "alert": { "title": "Game Request", "body": "Jeff wanna play with you", "action-loc-key": "PLAY" }, "badge": 5 } }

연락처 정보 수집 절차

사용자 단말이 구독(subscribe) 요청을 보내면 user 정보(email)와 device 정보(token)가 DB에 저장된다.

개략적 설계안

이벤트 서비스 : 외부에서 들어오는 요청이기 때문에 관심없다.
알림 서버 : 알림 서버를 적절한 큐로 보낸다. 로깅도 한다.
Queue : Adapter와 알림 서버 사이의 버퍼 역할, Adapter 별로 하나씩 있다.
Adapter : 각 서드 파티 알림 서비스별로 형식을 맞춘다.
제 3자 서비스 : 알림을 실제로 전달하는 서비스, 확장성 있게 설계해야 한다.

특징

알림 서버를 수평 확장성 있게 구성해서 SPOF 문제를 해결하고 캐시를 통해 stateless 유지
Queue를 통해 알림 서버와 Adapter 사이의 결합을 끊고 서로 확장성 있게 구현

알림 서버의 기능

인증(Authentication) : 인증된 클라이언트가 알림을 생성한다.
검증(Validation) : 이메일, 전화번호 등에 대한 검증을 진행한다.

상세 설계

안정성

데이터 손설 방지 : 로그를 남기고 실패가 날 경우 재시도 한다.
중복 전송 방지 : 이벤트 ID를 검사해서 중복을 최대한 없앤다. 100%는 불가능
It’s usually causal ordering that we’re after anyway. People who say otherwise don’t quite realize that there is no now in a distributed system.

추가 컴포넌트

알림 템플릿 : 변수를 주입 가능한 템플릿을 만들어서 쓴다. 주로 .tpl일려나?
알림 설정 : 알림 상세 설정 기능을 도입하고 알림을 보내기 전 검사한다.
전송률 제한
재시도 방법 : 알림 전송에 실패하면 재시도 전용 큐에 넣고, 개발자에게 알림
푸시 알림과 보안 : 인증된 클라이언트만 알림을 생성할 수 있어야 한다. STS 쓰면 되나?
큐 모니터링 : 큐에 쌓인 알림 수를 기준으로 scaling한다.
이벤트 추적 : 돈 되는 지표를 뽑는다. (클릭율, 확인율 등)

수정된 설계안

💡
아래 두 그림 중 어느 것이 더 나은가…
https://cloudificationzone.com/2021/08/13/notification-system-design/
https://leandrofranchi.medium.com/how-to-design-a-notification-system-23f381cdeb00