Kepiye carane ngirim kode promo menyang 1 yuta pangguna ing sajroning wektu sing cendhak?

Question

IT Interview Practice · Accepted Answer

Aja tau nglakoni loop marang 1 yuta pangguna ing sajroning request handler — **sebar (fan out) liwat antrian (queue)**, watesi kacepetane cocog karo apa sing bisa ditampa saben provider, gawe saben pangiriman **idempotent**, lan arahake kegagalan menyang DLQ kanggo dicoba maneh. Panggilan API mung nglebokake menyang antrian; worker sing nindakake I/O sing alon.

## 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 lan aliran

- **Campaign API** nyerat kampanye lan nglebokake job menyang antrian — siji saben pangguna utawa saben **batch ~500** kanggo ngurangi overhead antrian. Iki langsung mbalik (return); 1 yuta pangiriman kedadeyan ing mburi antrian.
- **Queue (Kafka / SQS)** minangka buffer lan log *replay*. Yen worker crash, pesen tetep ana ing panggonane; ora ana kode sing ilang. Partisi miturut `user_id` supaya urutan saben pangguna tetep stabil.
- **Worker pool** narik job lan autoscale adhedhasar keterlambatan (lag) antrian. Saben worker: (1) nyadhiyakake kode promo sing unik, (2) mriksa **dedup key** `SETNX sent:{campaign}:{user}` ing Redis supaya pesen sing dikirim maneh ora tau ngirim pindho, (3) ngliwati **rate limiter** sing diukur miturut kuota provider, (4) nyeluk Email/SMS/Push.
- **Rate limiter** iku intine: SendGrid utawa Twilio bakal nge-throttle utawa nge-blacklist sampeyan yen ngluwihi watesane. Token bucket Redis saben provider mbatesi RPS metu ora preduli sepira akehe worker sing mlaku.
- **DLQ** nangkep pesen beracun (poison) sawise N nyoba maneh nganggo exponential backoff + jitter, supaya alamat sing salah ora tau ngalang-alangi kampanye.

## Sudut pandang wawancara

Pewawancara nyoba niteni apa sampeyan ngerti **decoupling lan back-pressure**. Jawaban sing "apik banget" nyebutake kegagalan sing pas: tanpa idempotency, antrian at-least-once ditambah retry padha karo pangguna nampa telung kode; tanpa rate limiter, sampeyan nge-DDoS provider dhewe lan di-throttle nganti nol. Jebakan sing umum yaiku nindakake fan-out kanthi sinkron ("cukup `Promise.all`") — iki nyekel koneksi, ora duwe retry, lan ngilangi kabeh nalika deploy.

## Trade-off lan kegagalan

- **At-least-once vs exactly-once**: antrian menehi at-least-once kanthi murah; sampeyan tuku "effectively once" nganggo dedup key Redis, dudu nganggo broker exactly-once sing larang.
- **Throughput vs watesan provider**: sampeyan bisa nambah worker terus-terusan, nanging kuota provider iku plafon sing sanyatane — jaluk tambahan kuota utawa pre-warm sadurunge kampanye.
- **Kegagalan**: Redis mati → pangiriman mandheg (fail closed, aja nglewati dedup lan ngambil risiko pindho). Lacak counter saben kampanye supaya sampeyan bisa nerusake, dudu miwiti maneh, sawise insiden.

Arsitektur

Komponen lan aliran

Sudut pandang wawancara

Trade-off lan kegagalan

Pitakon sing gegandhengan