குறுகிய நேரத்தில் 1M பயனர்களுக்கு promo code-களை எப்படி அனுப்புவீர்கள்?

Question

IT Interview Practice · Accepted Answer

ஒரு request handler-க்குள் 1M பயனர்கள் மீது loop போட வேண்டாம் — **queue மூலம் fan out செய்யுங்கள்**, ஒவ்வொரு provider ஏற்றுக்கொள்ளக்கூடியதற்கு ஏற்ப throttle செய்யுங்கள், ஒவ்வொரு அனுப்புதலையும் **idempotent** ஆக்குங்கள், மேலும் தோல்விகளை retry-க்காக ஒரு 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
```

## கூறுகளும் ஓட்டமும்

- **Campaign API** campaign-ஐ எழுதி job-களை enqueue செய்கிறது — ஒரு பயனருக்கு ஒன்று அல்லது **~500 என்ற batch**-க்கு ஒன்று, queue overhead-ஐக் குறைக்க. இது உடனடியாகத் திரும்புகிறது; 1M அனுப்புதல்கள் queue-க்குப் பின்னால் நடக்கின்றன.
- **Queue (Kafka / SQS)** என்பது buffer மற்றும் *replay* log ஆகும். workers crash ஆனாலும், messages அப்படியே இருக்கும்; எந்தக் குறியீடும் இழக்கப்படாது. ஒரு பயனருக்கான ordering நிலையாக இருக்க `user_id` மூலம் partition செய்யுங்கள்.
- **Worker pool** job-களை pull செய்து queue lag-இன் அடிப்படையில் autoscale செய்கிறது. ஒவ்வொரு worker: (1) ஒரு தனித்துவமான promo code-ஐ reserve செய்கிறது, (2) Redis-இல் ஒரு **dedup key** `SETNX sent:{campaign}:{user}` சரிபார்க்கிறது, இதனால் மீண்டும் வழங்கப்பட்ட message ஒருபோதும் இரட்டை அனுப்புதல் செய்யாது, (3) provider-இன் quota-க்கு ஏற்ப அளவிடப்பட்ட ஒரு **rate limiter** வழியாகச் செல்கிறது, (4) Email/SMS/Push-ஐ அழைக்கிறது.
- **Rate limiter** தான் மையம்: SendGrid அல்லது Twilio அவற்றின் வரம்பைத் தாண்டினால் உங்களை throttle செய்யும் அல்லது blacklist செய்யும். ஒவ்வொரு provider-க்கும் ஒரு Redis token bucket, எத்தனை workers இயங்கினாலும் outbound RPS-ஐ cap செய்கிறது.
- **DLQ** exponential backoff + jitter உடன் N retries-க்குப் பிறகு poison messages-ஐப் பிடிக்கிறது, இதனால் ஒரு தவறான முகவரி campaign-ஐத் தடுக்காது.

## நேர்காணல் கண்ணோட்டம்

உங்களுக்கு **decoupling மற்றும் back-pressure** புரிகிறதா என்பதை நேர்காணல் செய்பவர் ஆராய்கிறார். ஒரு "சிறந்த" பதில் சரியான தோல்வியைக் குறிப்பிடும்: idempotency இல்லாமல், at-least-once queue மற்றும் ஒரு retry சேர்ந்தால் பயனர்கள் மூன்று code-கள் பெறுவார்கள்; rate limiter இல்லாமல், நீங்களே provider-ஐ self-DDoS செய்து zero வரை throttle செய்யப்படுவீர்கள். பொதுவான பொறி என்னவென்றால் fan-out-ஐ synchronous-ஆகச் செய்வது ("just `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 செய்யுங்கள்.
- **தோல்வி**: Redis down → அனுப்புதல்கள் நிற்கும் (fail closed செய்யுங்கள், dedup-ஐத் தவிர்த்து இரட்டைகளின் அபாயத்தை எடுக்காதீர்கள்). ஒரு சம்பவத்திற்குப் பிறகு restart அல்ல, resume செய்ய, ஒவ்வொரு campaign-க்கும் ஒரு counter-ஐ கண்காணியுங்கள்.

கட்டமைப்பு

கூறுகளும் ஓட்டமும்

நேர்காணல் கண்ணோட்டம்

சமரசங்களும் தோல்வியும்

தொடர்புடைய கேள்விகள்