Bagaimana anda menghantar kod promo kepada 1J pengguna dalam tempoh yang singkat?

Question

IT Interview Practice · Accepted Answer

Jangan sekali-kali gelung ke atas 1J pengguna di dalam pengendali permintaan (request handler) — **fan out melalui queue**, throttle mengikut kadar yang boleh diterima setiap provider, jadikan setiap penghantaran **idempotent**, dan halakan kegagalan ke DLQ untuk cuba semula. Panggilan API hanya melakukan enqueue; worker yang melakukan I/O yang perlahan.

## Seni bina

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

- **Campaign API** menulis kempen dan melakukan enqueue job — satu bagi setiap pengguna atau bagi setiap **batch ~500** untuk mengurangkan overhead queue. Ia kembali serta-merta; penghantaran 1J berlaku di belakang queue.
- **Queue (Kafka / SQS)** ialah penampan dan log *replay*. Jika worker crash, mesej kekal di tempatnya; tiada kod hilang. Partition mengikut `user_id` supaya penyusunan (ordering) bagi setiap pengguna adalah stabil.
- **Worker pool** menarik job dan melakukan autoscale berdasarkan queue lag. Setiap worker: (1) menempah kod promo yang unik, (2) menyemak **dedup key** `SETNX sent:{campaign}:{user}` di Redis supaya mesej yang dihantar semula tidak pernah menghantar dua kali, (3) melepasi **rate limiter** yang bersaiz mengikut kuota provider, (4) memanggil Email/SMS/Push.
- **Rate limiter** ialah intipatinya: SendGrid atau Twilio akan throttle atau menyekat (blacklist) anda jika melebihi had mereka. Sebuah Redis token bucket bagi setiap provider mengehadkan outbound RPS tanpa mengira berapa banyak worker berjalan.
- **DLQ** menangkap mesej beracun (poison messages) selepas N kali cuba semula dengan exponential backoff + jitter, supaya satu alamat yang buruk tidak pernah menyekat kempen.

## Perspektif temu duga

Penemu duga sedang menyiasat sama ada anda memahami **decoupling dan back-pressure**. Jawapan yang "hebat" menyebut kegagalan yang tepat: tanpa idempotency, sebuah queue at-least-once ditambah retry bersamaan pengguna menerima tiga kod; tanpa rate limiter, anda men-DDoS provider sendiri dan di-throttle sehingga sifar. Perangkap biasa ialah melakukan fan-out secara segerak ("guna sahaja `Promise.all`") — ini mengikat connection, tiada retry, dan hilang segalanya semasa deploy.

## Pertukaran 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 had provider**: anda boleh menambah worker selamanya, tetapi kuota provider ialah siling sebenar — minta kenaikan kuota atau lakukan pre-warm sebelum kempen.
- **Kegagalan**: Redis tumbang → penghantaran tergendala (fail closed, jangan langkau dedup dan berisiko menghantar dua kali). Jejak kaunter setiap kempen supaya anda boleh menyambung semula (resume), bukan mula semula (restart), selepas insiden.

Seni bina

Komponen dan aliran

Perspektif temu duga

Pertukaran dan kegagalan

Soalan berkaitan