Bagaimana Anda mengirim kode promo ke 1 juta pengguna dalam jendela waktu yang singkat?

Question

IT Interview Practice · Accepted Answer

Jangan pernah melakukan loop terhadap 1 juta pengguna di dalam request handler — **sebarkan (fan out) melalui queue**, throttle sesuai kapasitas yang bisa diterima setiap provider, buat setiap pengiriman **idempotent**, dan arahkan kegagalan ke DLQ untuk retry. Panggilan API hanya melakukan enqueue; worker yang mengerjakan I/O yang lambat.

## Arsitektur

```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
```

## Komponen dan alur

- **Campaign API** menulis kampanye dan meng-enqueue job — satu per pengguna atau per **batch berisi ~500** untuk mengurangi overhead queue. API kembali secara instan; 1 juta pengiriman terjadi di balik queue.
- **Queue (Kafka / SQS)** adalah buffer sekaligus log *replay*. Jika worker crash, pesan tetap ada; tidak ada kode yang hilang. Partisi berdasarkan `user_id` agar urutan per pengguna tetap stabil.
- **Worker pool** menarik job dan melakukan autoscale berdasarkan queue lag. Setiap worker: (1) memesan kode promo yang unik, (2) memeriksa **dedup key** `SETNX sent:{campaign}:{user}` di Redis agar pesan yang dikirim ulang tidak pernah mengirim ganda, (3) melewati **rate limiter** yang diukur sesuai kuota provider, (4) memanggil Email/SMS/Push.
- **Rate limiter** adalah intinya: SendGrid atau Twilio akan melakukan throttle atau blacklist jika Anda melampaui limit mereka. Sebuah Redis token bucket per provider membatasi RPS keluar tanpa peduli berapa banyak worker yang berjalan.
- **DLQ** menangkap poison message setelah N kali retry dengan exponential backoff + jitter, sehingga satu alamat yang buruk tidak pernah memblokir kampanye.

## Perspektif wawancara

Pewawancara menguji apakah Anda memahami **decoupling dan back-pressure**. Jawaban yang "hebat" menyebut kegagalan spesifiknya: tanpa idempotency, queue at-least-once ditambah retry berarti pengguna menerima tiga kode; tanpa rate limiter, Anda mem-DDoS provider sendiri dan di-throttle hingga nol. Jebakan umum adalah melakukan fan-out secara sinkron ("cukup `Promise.all`") — itu mengikat koneksi, tidak punya retry, dan kehilangan semuanya saat deploy.

## Trade-off dan kegagalan

- **At-least-once vs exactly-once**: queue memberi at-least-once dengan murah; Anda membeli "effectively once" dengan Redis dedup key, bukan dengan broker exactly-once yang mahal.
- **Throughput vs limit provider**: Anda bisa menambah worker selamanya, tetapi kuota provider adalah batas atas yang sesungguhnya — minta kenaikan kuota atau lakukan pre-warm sebelum kampanye.
- **Kegagalan**: Redis down → pengiriman terhenti (fail closed, jangan lewati dedup dan berisiko ganda). Lacak counter per kampanye agar Anda bisa melanjutkan (resume), bukan mengulang dari awal, setelah insiden.

Arsitektur

Komponen dan alur

Perspektif wawancara

Trade-off dan kegagalan

Pertanyaan terkait