ਤੁਸੀਂ ਇੱਕ ਛੋਟੇ window ਵਿੱਚ 10 ਲੱਖ users ਨੂੰ promo codes ਕਿਵੇਂ ਭੇਜਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

ਕਿਸੇ request handler ਵਿੱਚ 10 ਲੱਖ users ਉੱਤੇ ਕਦੇ loop ਨਾ ਚਲਾਓ — **queue ਰਾਹੀਂ fan out ਕਰੋ**, ਹਰ provider ਜਿੰਨਾ ਸਵੀਕਾਰ ਕਰ ਸਕੇ ਓਨਾ ਹੀ throttle ਕਰੋ, ਹਰ send ਨੂੰ **idempotent** ਬਣਾਓ, ਅਤੇ failures ਨੂੰ retry ਲਈ DLQ ਵੱਲ route ਕਰੋ। API call ਸਿਰਫ਼ enqueue ਕਰਦੀ ਹੈ; ਹੌਲੀ I/O ਦਾ ਕੰਮ workers ਕਰਦੇ ਹਨ।

## ਆਰਕੀਟੈਕਚਰ

```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** campaign ਨੂੰ ਲਿਖਦੀ ਹੈ ਅਤੇ jobs enqueue ਕਰਦੀ ਹੈ — queue overhead ਘਟਾਉਣ ਲਈ ਹਰ user ਲਈ ਇੱਕ ਜਾਂ **~500 ਦੇ batch** ਲਈ ਇੱਕ। ਇਹ ਤੁਰੰਤ return ਕਰ ਦਿੰਦੀ ਹੈ; 10 ਲੱਖ sends queue ਦੇ ਪਿੱਛੇ ਹੁੰਦੇ ਹਨ।
- **Queue (Kafka / SQS)** buffer ਅਤੇ *replay* log ਹੈ। ਜੇ workers crash ਹੋ ਜਾਣ, messages ਥਾਂ ਉੱਤੇ ਹੀ ਰਹਿੰਦੇ ਹਨ; ਕੋਈ code ਨਹੀਂ ਗੁਆਚਦਾ। `user_id` ਨਾਲ partition ਕਰੋ ਤਾਂ ਜੋ ਹਰ user ਲਈ ordering ਸਥਿਰ ਰਹੇ।
- **Worker pool** jobs ਖਿੱਚਦਾ ਹੈ ਅਤੇ queue lag ਉੱਤੇ autoscale ਕਰਦਾ ਹੈ। ਹਰ worker: (1) ਇੱਕ ਵਿਲੱਖਣ promo code reserve ਕਰਦਾ ਹੈ, (2) Redis ਵਿੱਚ ਇੱਕ **dedup key** `SETNX sent:{campaign}:{user}` ਚੈੱਕ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਦੁਬਾਰਾ ਭੇਜਿਆ ਗਿਆ message ਕਦੇ double-send ਨਾ ਕਰੇ, (3) provider ਦੇ quota ਮੁਤਾਬਕ ਸਾਈਜ਼ ਕੀਤੇ **rate limiter** ਵਿੱਚੋਂ ਲੰਘਾਉਂਦਾ ਹੈ, (4) Email/SMS/Push call ਕਰਦਾ ਹੈ।
- **Rate limiter** ਹੀ ਅਸਲ ਗੱਲ ਹੈ: SendGrid ਜਾਂ Twilio ਆਪਣੀ limit ਤੋਂ ਉੱਪਰ ਤੁਹਾਨੂੰ throttle ਜਾਂ blacklist ਕਰ ਦੇਣਗੇ। ਹਰ provider ਲਈ ਇੱਕ Redis token bucket outbound RPS ਨੂੰ cap ਕਰਦਾ ਹੈ, ਭਾਵੇਂ ਕਿੰਨੇ ਵੀ workers ਚੱਲ ਰਹੇ ਹੋਣ।
- **DLQ** N retries (exponential backoff + jitter ਸਮੇਤ) ਤੋਂ ਬਾਅਦ poison messages ਫੜ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਜੋ ਇੱਕ ਗਲਤ address ਪੂਰੀ campaign ਨੂੰ ਕਦੇ block ਨਾ ਕਰੇ।

## ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਇੰਟਰਵਿਊਅਰ ਇਹ ਪਰਖ ਰਿਹਾ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ **decoupling ਅਤੇ back-pressure** ਸਮਝਦੇ ਹੋ। ਇੱਕ "ਵਧੀਆ" ਜਵਾਬ ਠੀਕ ਓਸ failure ਦਾ ਨਾਂ ਲੈਂਦਾ ਹੈ: idempotency ਤੋਂ ਬਿਨਾਂ, ਇੱਕ at-least-once queue ਨਾਲ ਇੱਕ retry ਦਾ ਮਤਲਬ ਹੈ users ਨੂੰ ਤਿੰਨ codes ਮਿਲਣਾ; rate limiter ਤੋਂ ਬਿਨਾਂ, ਤੁਸੀਂ provider ਉੱਤੇ ਖੁਦ-DDoS ਕਰਦੇ ਹੋ ਅਤੇ ਜ਼ੀਰੋ ਤੱਕ throttle ਹੋ ਜਾਂਦੇ ਹੋ। ਆਮ ਫੰਦਾ ਹੈ fan-out ਨੂੰ synchronously ਕਰਨਾ ("ਬਸ `Promise.all`") — ਇਹ connections ਬੰਨ੍ਹ ਦਿੰਦਾ ਹੈ, ਕੋਈ retry ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ deploy ਹੋਣ ਉੱਤੇ ਸਭ ਕੁਝ ਗੁਆ ਦਿੰਦਾ ਹੈ।

## ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ

- **At-least-once vs exactly-once**: queues ਸਸਤੇ ਵਿੱਚ at-least-once ਦਿੰਦੀਆਂ ਹਨ; ਤੁਸੀਂ "effectively once" Redis dedup key ਨਾਲ ਖਰੀਦਦੇ ਹੋ, ਨਾ ਕਿ ਮਹਿੰਗੇ exactly-once broker ਨਾਲ।
- **Throughput vs provider limits**: ਤੁਸੀਂ ਹਮੇਸ਼ਾ workers ਵਧਾ ਸਕਦੇ ਹੋ, ਪਰ provider quota ਹੀ ਅਸਲ ਛੱਤ ਹੈ — campaign ਤੋਂ ਪਹਿਲਾਂ quota bump ਮੰਗੋ ਜਾਂ pre-warm ਕਰੋ।
- **Failure**: Redis down → sends ਰੁਕ ਜਾਂਦੇ ਹਨ (fail closed ਕਰੋ, dedup skip ਕਰ ਕੇ doubles ਦਾ ਖਤਰਾ ਨਾ ਲਓ)। ਹਰ campaign ਲਈ ਇੱਕ counter track ਕਰੋ ਤਾਂ ਜੋ ਕਿਸੇ incident ਤੋਂ ਬਾਅਦ ਤੁਸੀਂ resume ਕਰ ਸਕੋ, restart ਨਹੀਂ।

ਆਰਕੀਟੈਕਚਰ

ਕੰਪੋਨੈਂਟ ਅਤੇ ਫਲੋ

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ

ਸੰਬੰਧਿਤ ਸਵਾਲ