તમે ટૂંકા સમયગાળામાં 1M યુઝર્સને પ્રોમો કોડ કેવી રીતે મોકલશો?

Question

IT Interview Practice · Accepted Answer

રિક્વેસ્ટ હેન્ડલરમાં ક્યારેય 1M યુઝર્સ પર લૂપ ન કરો — **queue દ્વારા fan out કરો**, દરેક provider જે સ્વીકારી શકે તેટલા સુધી throttle કરો, દરેક send ને **idempotent** બનાવો, અને retry માટે failures ને DLQ પર route કરો. API કૉલ માત્ર 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
```

## કમ્પોનન્ટ્સ અને flow

- **Campaign API** કૅમ્પેઇન લખે છે અને jobs enqueue કરે છે — queue overhead ઘટાડવા માટે એક પ્રતિ યુઝર અથવા **~500 નું batch** પ્રતિ. તે તરત જ return કરે છે; 1M sends queue પાછળ થાય છે.
- **Queue (Kafka / SQS)** એ buffer અને *replay* log છે. જો workers crash થાય, messages ત્યાં જ રહે છે; કોઈ code ખોવાતો નથી. `user_id` દ્વારા partition કરો જેથી પ્રતિ યુઝર ordering સ્થિર રહે.
- **Worker pool** jobs pull કરે છે અને queue lag પર autoscale થાય છે. દરેક worker: (1) એક unique પ્રોમો કોડ reserve કરે છે, (2) Redis માં **dedup key** `SETNX sent:{campaign}:{user}` તપાસે છે જેથી ફરીથી ડિલિવર થયેલો message ક્યારેય double-send ન કરે, (3) provider ના quota અનુસાર બનાવેલા **rate limiter** માંથી પસાર થાય છે, (4) Email/SMS/Push કૉલ કરે છે.
- **Rate limiter** એ મુખ્ય મુદ્દો છે: SendGrid અથવા Twilio તેમની limit થી ઉપર તમને throttle અથવા blacklist કરશે. પ્રતિ provider એક Redis token bucket, ભલે ગમે તેટલા workers ચાલતા હોય, outbound RPS ને cap કરે છે.
- **DLQ** exponential backoff + jitter સાથે N retries પછી poison messages ને પકડે છે, જેથી એક ખરાબ address ક્યારેય કૅમ્પેઇન ને block ન કરે.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર તપાસી રહ્યા છે કે તમે **decoupling અને back-pressure** સમજો છો કે નહીં. એક "શ્રેષ્ઠ" જવાબ ચોક્કસ failure નું નામ આપે છે: idempotency વગર, at-least-once queue વત્તા એક retry એટલે યુઝર્સ ને ત્રણ કોડ મળે છે; rate limiter વગર, તમે provider પર self-DDoS કરો છો અને શૂન્ય સુધી throttle થાઓ છો. સામાન્ય trap એ fan-out ને synchronously કરવાનું છે ("just `Promise.all`") — તે connections બાંધી રાખે છે, કોઈ retry નથી, અને deploy પર બધું ગુમાવે છે.

## Trade-offs અને failure

- **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 એ ખરી છત છે — quota bump માટે request કરો અથવા કૅમ્પેઇન પહેલાં pre-warm કરો.
- **Failure**: Redis down → sends stall (fail closed કરો, dedup skip કરીને doubles નું જોખમ ન લો). પ્રતિ-કૅમ્પેઇન counter track કરો જેથી incident પછી તમે restart નહીં પણ resume કરી શકો.

આર્કિટેક્ચર

કમ્પોનન્ટ્સ અને flow

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure

સંબંધિત પ્રશ્નો