Alarm Notification Proposal

알람 설계 proposal

Pain points

1. 서버리스 시스템인 google cloud run앱(이하 api서버)에서 event를 어떻게 스케쥴링 할 것인가?
   • cloud task vs cloud pub/sub vs cloud scheduler
2. api서버에서 event에 들어가야할 상태가 변경된다면 어떻게 관리해야 하는가?
   • 교환일기방의 작성순서가 변경 되었을 때 --> callback에서 db 한번 retrieve하니까, 수정된 up-to-date 상태가 반영됨
   • 교환일기방에 멤버가 참여 / 나가기 했을 때 --> broadcast알림은 up-to-date이니 신경쓰지 않아도됨, 문제는 만약 글쓴이 본인이 탈퇴할 경우인데, 이 또한 예약된 일정동안 글을 작성하는 이벤트를 만들지 않는다면, 자동으로 다음턴이 진행된다. 즉 두 경우 모두 신경쓰지 않아도 된다.
   • 교환일기방이 삭제 되었을 때 --> callback에서 roomID retrieve시 교환일기방이 존재하지 않는다면, 202로 무시할 수 있게 스펙 생성
3. ios / aos에게 메시지를 전달
   • firebase notification
   • cloud task에서 firebase notification에 어떻게 event를 전달할 수 있을까?
     • api 서버 우회 방법
       • cloud task에서 예약된 시점에 api서버로 firebase에 메시지 쏴야한다는 request를 주어 로직 처리
     • firebase function을 작성하는 방법
       • cloud task에서 예약된 시점에 firebase function으로 요청을 보내어 firebase notification 트리거함.

Cloud Task vs Cloud pubsub

• 이벤트 시점 스케쥴링 가능하다는 점에서 cloud task 선택
• google cloud scheduler는 cronjob을 지원하지만, 태스크를 3개만 등록 가능한데, room의 갯수 만큼 태스크를 만들어야 하는 voda 서버에는 맞지 않다.

Event list

voda 서버에서 처리해야하는 event를 분류합니다.

app alarm event

실제 유저에게 전달되는 events

• single alarm

  1. 작성자 작성 1시간 전(code: M11)
  2. 작성자 작성 4시간 전(code: M12)
  3. 작성자 최초 선정 되었을 때(code: M13)

• broadcast alarm

  1. 새글 작성 (code: M2)
     • 교환일기방에 글이 작성 될 때 initial entry point
     • 해당 room_id에 속한 멤버들에게 alarm

app alarm trigger event

앱 알람을 트리거 하기 위해 필요한 events

• 교환일기 방의 작성주기가 종료 되었는가? (code: R1)
  • R2, M13 requeue
  • 교환일기방이 최초 생성 시점에 initial entry point
• 교환일기 방 새로운 작성 이벤트(R1) 등록 (code: R2)
  1. 교환일기방이 존재하지 않을 경우
     • :room_id에 할당된 cloud task에서 task 제거
  2. 교환일기 방이 존재할 경우
     • R1, M11, M12 트리거

from exchange-diary.

deviceToken 관련 refs

voda 정책

• POST /token 요청을 보낼때, authCode랑 deviceToken(string)을 클라에서 준다.

• 서버에서는 authCode의 유저가 deviceToken을 기존에 db에 저장하고 있지만, post로 전달 된 deviceToken을 가지고 있지 않는다면 다중 디바이스로 간주하고 추가.

• 이후 서버쪽에서 파이어베이스(FCM)로 메시지 보낼 때, 토큰 만료 메시지 받는 경우에는 해당 deviceToken은 만료되었다고 간주하고, 삭제

from exchange-diary.