요구사항과 두 종류의 알림

평균과 피크의 차이, 그리고 폭주하는 쪽이 어느 종류인지입니다.

하루 5천만 건 은 평균 초당 578건이라 처리량이 부담이 아닙니다. 그런데 마케팅 발송이 시작되면 피크 초당 1만 이 됩니다.

폭주하는 쪽이 급하지 않은 알림이라는 것이 핵심입니다. 비밀번호 재설정 알림이 마케팅 뒤에 줄을 서면 1분 요구를 어깁니다.

그래서 급한 것과 급하지 않은 것을 같은 줄에 세우지 않습니다.

흔한 실수: 평균 처리량만 보고 설계하는 것. 이 시스템의 어려움은 총량이 아니라 한 서비스의 발송이 다른 서비스의 알림을 밀어내는 것입니다. 여러 서비스가 함께 쓰는 플랫폼이라 더 그렇습니다.

우리 시스템이 사용자 데이터베이스를 알 필요가 없어집니다.

"30일 미접속 사용자에게" 같은 조건으로 대상을 뽑는 일은 각 서비스가 압니다. 우리는 받는 사람 목록과 내용을 받아 보내는 일만 합니다.

서비스: 누구에게 무엇을 보낼지 정한다
알림 플랫폼: 받아서 보낸다

경계를 이렇게 그으면 각 서비스의 데이터 모델 변화가 우리에게 오지 않습니다.

흔한 실수: 편의를 위해 조건 기반 발송을 받아들이는 것. "이 조건에 맞는 사용자에게 보내 줘" 를 받으면 모든 서비스의 데이터를 우리가 알아야 하고, 그 순간 플랫폼이 아니라 각 서비스의 일부가 됩니다.

기본으로 두면 안 됩니다. 채널마다 성질이 크게 다릅니다.

문자는 비용이 들고, 세 곳에서 같은 알림을 받으면 사용자가 짜증을 냅니다. 짜증은 곧 전체 수신 거부로 이어집니다.

흔한 실수: 도달률을 높이려고 여러 채널을 함께 쓰는 것. 중요한 알림에서는 맞지만 기본값으로 두면 비용과 신뢰를 함께 잃습니다. 어느 채널로 보낼지가 알림 종류마다의 판단입니다.

발송 직전입니다. 대상 목록을 만든 시점이 아닙니다.

목록을 만든 시점과 실제 발송 사이에 사용자가 거부했을 수 있습니다. 목록이 100만 건이면 발송에 시간이 걸리므로 그 시차가 커집니다.

목록 생성 시점에 확인하면 그 뒤의 거부를 놓친다
발송 직전에 확인하면 시차가 없다

수신 거부는 우리가 정하는 정책이 아니라 법적 요구입니다. 어기면 서비스 전체가 위험해집니다.

흔한 실수: 목록을 만들 때 걸러내고 끝내는 것. 대량 발송에서 첫 건과 마지막 건 사이에 몇 시간이 지날 수 있습니다. 그 사이에 거부한 사용자에게 보내면 어긴 것입니다.