전사(company-wide) 알림 서비스를 어떻게 설계하시겠습니까?

Question

IT Interview Practice · Accepted Answer

모든 팀이 **알림 유형 + 수신자**로 호출하는 하나의 서비스를 만들고, 그 서비스가 채널, 템플릿, 사용자 선호(preference), 우선순위를 해석하도록 하십시오. 핵심 설계 결정은 **우선순위 레인(priority lanes)**입니다 — OTP는 200만 사용자 대상 마케팅 대량 발송 뒤에서 기다릴 수 없습니다.

## 아키텍처

```text
Services ─▶ Notify API ─▶ [validate + enrich] ─▶ Kafka topics
                                                 ├─ otp/txn  (high lane)
                                                 └─ marketing (bulk lane)
                                                      │
                            ┌──── Dispatcher (per lane) ────┐
                            │ prefs check ─▶ template render │
                            └────┬──────┬──────┬────────────┘
                              Push   Email   SMS   In-App
                                 (provider adapters + rate limit)
```

## 구성 요소와 흐름

- **Notify API**는 타입이 지정된 요청을 받습니다: `{type: "otp", user, data}`. 호출자는 채널을 고르거나 문구를 작성하지 않으며 — 서비스가 그것을 소유하므로 템플릿 변경은 한 번만 배포하면 됩니다.
- **Type → policy**: 각 **type**은 정책에 매핑됩니다. *OTP*는 high-priority, SMS+Push, 마케팅 수신 거부를 무시하며 60초 후 만료됩니다. *Transactional*(영수증, 비밀번호 재설정)은 high이며 채널 선호를 존중합니다. *Marketing*은 low, bulk lane이며 수신 거부와 방해 금지 시간(quiet hours)을 엄격히 준수합니다.
- **우선순위 레인(Priority lanes)**은 별도의 consumer group을 가진 별도의 Kafka topic입니다. high lane은 거의 비어 있어 밀리초 만에 비워지고, bulk lane은 OTP latency를 건드리지 않고 몇 분간 밀려도 됩니다. 이것이 가장 중요한 단 하나의 결정입니다.
- **선호 서비스(Preference service)**는 수신자마다 확인됩니다: 수신 거부했는가? 방해 금지 시간인가? 채널별 토글은? 빈도 상한(frequency cap)은? 선호를 위반하는 마케팅은 여기서 폐기됩니다.
- **템플릿 엔진(Template engine)**은 버전 관리되는 템플릿 + 변수로 지역화된 콘텐츠를 렌더링하므로, 문구와 코드가 분리됩니다.
- **채널 어댑터(Channel adapters)**는 FCM/APNs, SendGrid, Twilio를 하나의 인터페이스 뒤로 감싸며, 각각 자체 rate limiter, 재시도, DLQ를 갖습니다(모든 대량 발송기와 동일한 팬아웃 규율).

## 면접 관점

면접관은 당신이 **관심사(concerns)**를 분리하는지 확인합니다: 많은 지원자가 이메일을 직접 보내는 monolith를 만들었다가 마케팅 폭주가 OTP를 지연시키는 것을 뒤늦게 발견합니다. *우선순위 레인*, *선호 강제 적용*, *idempotency 키*(재시도된 요청이 이중 알림을 보내지 않도록)를 짚는 것이 시니어의 신호입니다. 좋은 답변은 채널을 추가하고, 훌륭한 답변은 OTP와 마케팅이 절대 큐를 공유해서는 안 되는 이유와 **폴백 체인(fallback chain)**(Push 실패 → SMS)이 어떻게 작동하는지 설명합니다.

## 트레이드오프와 실패

- **단일 서비스 vs 팀별**: 중앙화는 일관된 선호, throttling, 감사(audit)를 제공하지만 중요한 의존성이 됩니다 — HA여야 하며, 그렇지 않으면 로그인 OTP 장애가 회사 전체를 막습니다.
- **실시간 vs 비용**: SMS는 비싸고 느립니다. Push/In-App을 선호하고 고가치 유형에만 SMS로 폴백하십시오.
- **실패**: provider 장애는 하드 실패가 아니라 폴백 체인을 유발합니다. **Dedup 키**는 큐 재전달이 OTP를 두 번 보내는 것을 막습니다. 유형별 전달 SLO를 추적하십시오 — 지연된 마케팅 이메일은 괜찮지만, 지연된 OTP는 인시던트입니다.

아키텍처

구성 요소와 흐름

면접 관점

트레이드오프와 실패

관련 질문