개요

1백만 명 이상의 사용자를 지원하는 강력한 신호 전송 시스템을 설계하세요. 시스템은 다음을 보장해야 합니다:

• 중복된 알림 없음
• 손실 없는 전송
• 공급자 장애 시 우아한 하락
• 확장성 및 관찰 가능성

고수준 아키텍처

Client/API
   ↓
Notification Service
   ↓
Message Queue (Kafka/SQS/RabbitMQ)
   ↓
Notification Workers
   ↓
Provider Adapters
(SendGrid, Twilio, Firebase, etc.)
   ↓
Webhook/Event Processor
   ↓
Notification Database + Audit Logs

핵심 구성 요소

1. 알림 API 서비스

처리:

• 알림 생성
• 유효성 검사
• 일관성 검사
• 메시지 큐에 추가

각 요청은 다음을 받습니다:

• 알림 ID
• idempotency_key

서비스는 처리 전 알림을 저장하여 지속성을 보장합니다.

2. 메시지 큐

비동기 처리에 사용되는 Kafka/SQS/RabbitMQ입니다.

장점:

• 생산자와 소비자를 분리합니다.
• 트래픽 피크를 흡수합니다.
• 재시도를 지원합니다.
• 요청 차단을 방지합니다.

메시지는 성공적으로 처리될 때까지 보관됩니다.

3. 알림 워커

전용 워커:

• 이메일
• SMS
• 푸시 알림

책임:

• 큐 메시지 소비
• 알림 전송
• 일시적 실패 재시도
• 배송 상태 업데이트

노동자들이 수평적으로 확장됩니다.

신뢰 전략

일관성

각 알림에는 다음이 포함됩니다:

• 고유한 notification_id
• 일관성_키

데이터베이스 제약 조건:

UNIQUE(idempotency_key)

발송 전:

• 알림이 이미 성공했는지 확인
• 반복 시 중복 전송 방지

재시도 & 실패 처리

실패 분류:

• 일시적 → 재시도
• 영구적 → 즉시 실패

재시도 전략:

• 지수적 백오프
• 사망 문자 큐 (DLQ)
• 최대 재시도 임계값

예시:

1 min → 5 min → 15 min → 1 hour

부드러운 하락

만약 제공자가 실패하면:

• 대체 제공자가 자동으로 활성화됩니다

예시:

Twilio fails → switch to Termii
SendGrid fails → switch to SES

캐빈저는 지속적으로 건강하지 않은 제공자를 호출하지 않도록 방지합니다.

배송 추적

웹훅 처리기는 다음을 수신합니다:

• 배달
• 실패
• 반려
• 열림 이벤트

모든 이벤트는 감사 테이블에 저장됩니다.

데이터베이스 설계

테이블:

• 알림
• 배송 시도
• 공급자 로그
• 템플릿
• 사용자 선호도

인덱스:

(user_id, created_at)
(status, channel)
(notification_id)

손실된 전송 방지

메시지 손실을 피하기 위해서:

• 큐에 넣기 전에 저장된 알림
• 트랜잭션 아웃박스 패턴 사용
• 조정 작업은 멈춘 알림을 검색합니다

예시:

PENDING > 10 mins → requeue

관찰성

모니터링:

• 큐 깊이
• 제공자 지연 시간
• 재시도 횟수
• 실패한 배달률

도구:

• Prometheus
• Grafana
• CloudWatch
• Sentry

이상한 실패 피크에 대한 경고가 트리거됩니다.

확장성

시스템은 다음을 통해 100만 명 이상의 사용자를 지원합니다.

• 수평적 워커 확장
• 분할된 큐
• 무상태 서비스
• Redis 캐싱
• 적용 가능한 경우 배치 처리

보안

• 암호화된 제공자 자격 증명
• 서명된 웹훅
• 요청 제한
• RBAC 관리자 접근
• 모든 알림 이벤트에 대한 감사 로깅

기술 스택 예시

• 백엔드: Node.js / Python
• 큐: Kafka 또는 SQS
• 데이터베이스: PostgreSQL
• 캐시: Redis
• 프로바이더: Twilio, Firebase, SendGrid
• 모니터링: Grafana + Prometheus
• 배포: Kubernetes/ECS