짧은 시간 안에 100만 명의 사용자에게 프로모 코드를 어떻게 보내시겠습니까?

Question

IT Interview Practice · Accepted Answer

요청 핸들러에서 100만 명의 사용자를 절대 루프로 순회하지 마십시오 — **큐를 통해 팬아웃(fan out)**하고, 각 provider가 수용할 수 있는 수준으로 throttle하며, 모든 전송을 **idempotent**하게 만들고, 실패는 재시도를 위해 DLQ로 라우팅하십시오. API 호출은 enqueue만 수행하고, 느린 I/O는 worker가 처리합니다.

## 아키텍처

```text
Admin ─▶ Campaign API ─▶ [enqueue job] ─▶ Kafka/SQS ─┐
                                                     ▼
   ┌──────────────── Worker pool (autoscaled) ───────────────┐
   │  claim ─▶ dedup(Redis SETNX) ─▶ rate-limiter ─▶ provider │
   └──────────┬──────────────────────────────┬───────────────┘
              │ ok                            │ fail (5xx/timeout)
              ▼                               ▼
        sent_log (DB)                    Retry (backoff) ─▶ DLQ
```

## 구성 요소와 흐름

- **Campaign API**는 캠페인을 기록하고 job을 enqueue합니다 — 큐 오버헤드를 줄이기 위해 사용자당 하나씩 또는 **약 500개 단위 batch**로 처리합니다. 즉시 반환되며, 100만 건의 전송은 큐 뒤에서 일어납니다.
- **큐(Kafka / SQS)**는 버퍼이자 *리플레이(replay)* 로그입니다. worker가 crash되어도 메시지는 그대로 남아 코드가 유실되지 않습니다. 사용자별 순서가 안정적이도록 `user_id`로 partition하십시오.
- **Worker pool**은 job을 pull하며 큐 lag에 따라 autoscale합니다. 각 worker는 (1) 고유한 프로모 코드를 예약하고, (2) Redis에서 **dedup 키** `SETNX sent:{campaign}:{user}`를 확인하여 재전달된 메시지가 절대 중복 전송되지 않도록 하며, (3) provider의 quota에 맞춘 **rate limiter**를 통과시키고, (4) Email/SMS/Push를 호출합니다.
- **Rate limiter**가 핵심입니다: SendGrid나 Twilio는 한도를 초과하면 throttle하거나 blacklist에 올립니다. provider별 Redis token bucket이 실행 중인 worker 수와 무관하게 outbound RPS를 제한합니다.
- **DLQ**는 exponential backoff + jitter로 N번 재시도한 뒤에도 실패하는 poison 메시지를 잡아내므로, 잘못된 주소 하나가 캠페인 전체를 막지 않습니다.

## 면접 관점

면접관은 당신이 **디커플링(decoupling)과 백프레셔(back-pressure)**를 이해하는지 확인합니다. "훌륭한" 답변은 정확한 실패 모드를 짚습니다: idempotency가 없으면 at-least-once 큐 + 재시도는 곧 사용자가 코드를 세 번 받는 것을 의미하고, rate limiter가 없으면 provider를 스스로 DDoS하여 throttle로 0에 수렴합니다. 흔한 함정은 팬아웃을 동기적으로 처리하는 것("그냥 `Promise.all`")입니다 — 연결을 묶어두고, 재시도가 없으며, 배포 시 모든 것을 잃습니다.

## 트레이드오프와 실패

- **At-least-once vs exactly-once**: 큐는 at-least-once를 저렴하게 제공합니다. "사실상 한 번(effectively once)"은 값비싼 exactly-once broker가 아니라 Redis dedup 키로 얻습니다.
- **Throughput vs provider 한도**: worker는 얼마든지 추가할 수 있지만, provider quota가 진짜 상한선입니다 — 캠페인 전에 quota 상향을 요청하거나 미리 warm-up하십시오.
- **실패**: Redis 다운 → 전송 중단(fail closed, dedup을 건너뛰어 중복을 감수하지 말 것). 인시던트 후 재시작이 아니라 재개할 수 있도록 캠페인별 카운터를 추적하십시오.

아키텍처

구성 요소와 흐름

면접 관점

트레이드오프와 실패

관련 질문