1단계 문제 이해 및 설계 범위 확정

• soft-real time 시스템으로 가능한 한 빨리 전달되어야 하지만 시스템에 부하가 걸렸을 때 약간의 지연은 무방
• iOS, AOS, 랩톱/데스크톱 디바이스 지원
• 알림은 클라이언트에서 만들거나 서버에서 스케줄링
• 알림 거부 가능(opt-out)
• 천만 건의 모바일 푸시알림, 백만건의 sms, 5백만 건의 email

2단계 개략적 설계안 제시 및 동의 구하기

알림 유형별 지원 방안

• iOS 푸시 알림

  • 알림제공자 : 알림 요청을 만들어 애플 푸시알림 서비스(APNS)에 보내는 주체

    • 단말토큰 : 알림 요청을 보내는데 필요한 고유 식별자
    • 페이로드 : 알림 내용을 담은 JSON 딕셔너리

    
    {
    "aps": {
    	"alert": {
    		"title": "Game Request",
    		"body": "Bob wants to play chess",
    		"action-loc-key":"PLAY"
    	},
    	"badge":5,
    },
    
    

  • APNS : 애플이 제공하는 원격 서비스로 푸시 알림을 장치로 보내는 역할을 담당

안드로이드 푸시 알림

• iOS와 비솟하나 FCM을 사용한다는 점이 다름

SMS 메시지

• Twillo, Nexmo 같은 제 3 사업자의 서비스를 이용함

Email

• 고유 이메일 서버 또는 상용 이메일 서비스
• 센드그리드, 메일침프

연락처 정보 수집 절차

• 사용자의 정보(단말토큰, 전화번호, 이메일 주소)등의 정보를 앱 설치하거나 처음으로 계정 등록하면 DB에 저장

알림 전송 및 수신 절차