알림 시스템
알림 유형
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