অল্প সময়ের মধ্যে ১০ লক্ষ ইউজারকে কীভাবে প্রোমো কোড পাঠাবেন?

Question

IT Interview Practice · Accepted Answer

রিকোয়েস্ট হ্যান্ডলারের মধ্যে কখনও ১০ লক্ষ ইউজারের উপর লুপ চালাবেন না — **একটি queue-এর মাধ্যমে fan out করুন**, প্রতিটি provider যতটা গ্রহণ করতে পারে ততটুকুতে throttle করুন, প্রতিটি send-কে **idempotent** করুন, এবং ব্যর্থতাগুলোকে retry-এর জন্য একটি DLQ-তে রুট করুন। API কল শুধু enqueue করে; ধীর I/O worker-রা করে।

## আর্কিটেকচার

```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** ক্যাম্পেইন লেখে এবং job enqueue করে — প্রতি ইউজারে একটি বা প্রতি **~৫০০-এর batch**-এ একটি, যাতে queue overhead কমে। এটি সঙ্গে সঙ্গে রিটার্ন করে; ১০ লক্ষ send queue-এর পেছনে ঘটে।
- **Queue (Kafka / SQS)** হলো buffer এবং *replay* log। worker crash করলে message রয়ে যায়; কোনো কোড হারায় না। `user_id` দিয়ে partition করুন যাতে প্রতি ইউজারের ordering স্থিতিশীল থাকে।
- **Worker pool** job টেনে নেয় এবং queue lag অনুযায়ী autoscale করে। প্রতিটি worker: (১) একটি unique প্রোমো কোড reserve করে, (২) Redis-এ একটি **dedup key** `SETNX sent:{campaign}:{user}` চেক করে যাতে redelivered message কখনও double-send না করে, (৩) provider-এর quota অনুযায়ী সাইজ করা একটি **rate limiter**-এর মধ্য দিয়ে যায়, (৪) Email/SMS/Push কল করে।
- **Rate limiter** হলো মূল বিষয়: SendGrid বা Twilio তাদের limit-এর উপরে গেলে আপনাকে throttle বা blacklist করবে। প্রতি provider-এ একটি Redis token bucket outbound RPS-কে সীমিত রাখে, যত worker-ই চলুক না কেন।
- **DLQ** exponential backoff + jitter সহ N বার retry-এর পর poison message ধরে রাখে, যাতে একটি খারাপ address কখনও ক্যাম্পেইন আটকে না দেয়।

## ইন্টারভিউ দৃষ্টিভঙ্গি

ইন্টারভিউয়ার যাচাই করছেন আপনি **decoupling ও back-pressure** বোঝেন কিনা। একটি "দারুণ" উত্তর সঠিক failure-টি নাম ধরে বলে: idempotency ছাড়া, at-least-once queue প্লাস একটি retry মানে ইউজাররা তিনটি করে কোড পাবে; rate limiter ছাড়া, আপনি নিজেই provider-কে self-DDoS করবেন এবং শূন্যে throttle হয়ে যাবেন। সাধারণ ফাঁদটি হলো fan-out synchronously করা ("just `Promise.all`") — এতে connection আটকে থাকে, retry থাকে না, এবং deploy-এ সব হারায়।

## ট্রেড-অফ ও ব্যর্থতা

- **At-least-once বনাম exactly-once**: queue সস্তায় at-least-once দেয়; আপনি "effectively once" কেনেন Redis dedup key দিয়ে, ব্যয়বহুল exactly-once broker দিয়ে নয়।
- **Throughput বনাম provider limit**: আপনি চিরকাল worker যোগ করতে পারেন, কিন্তু provider quota-ই আসল সীমা — ক্যাম্পেইনের আগে quota বৃদ্ধির অনুরোধ করুন বা pre-warm করুন।
- **Failure**: Redis down → send আটকে যায় (fail closed করুন, dedup এড়িয়ে double-এর ঝুঁকি নেবেন না)। প্রতি ক্যাম্পেইনে একটি counter রাখুন যাতে incident-এর পর আপনি restart নয়, resume করতে পারেন।

আর্কিটেকচার

কম্পোনেন্ট ও ফ্লো

ইন্টারভিউ দৃষ্টিভঙ্গি

ট্রেড-অফ ও ব্যর্থতা

সম্পর্কিত প্রশ্ন