Case study: notification system — push, SMS, email আর নির্ভরযোগ্য delivery

১ · সমস্যা আর পরিধি — কে, কাকে, কী, কখন জানাবে

ধরা যাক “খবরি” (কাল্পনিক) একটি বড় অ্যাপ-কোম্পানির ভেতরের notification প্ল্যাটফর্ম। কোম্পানির login সেবা OTP পাঠায়, wallet সেবা জানায় “৳৫০০ এসেছে”, অর্ডার সেবা জানায় “পার্সেল পথে”, আর marketing দল ঈদের আগে ৫০ লাখ মানুষকে অফার পাঠাতে চায়। প্রতিটি দল আলাদা করে SMS কোম্পানির সাথে চুক্তি, push-এর কোড আর retry লিখলে একই ভুল দশবার হয়, আর কেউ জানে না একজন মানুষ আজ মোট কতগুলো বার্তা পেলেন। তাই একটি সাধারণ প্ল্যাটফর্ম: সবাই একটি API ডাকে, বাকিটা প্ল্যাটফর্মের দায়।

পর্ব ৬-এর আট ধাপের কাঠামো ধরে এগোব: পরিধি, হিসাব, API, data model, ছবি, তিনটি deep dive, ভাঙন আর সারাংশ। প্রতিটি পুরোনো ধারণার জন্য এক বাক্য প্রয়োগ আর তার পর্বের link — নতুন করে শেখানো নয়।

Functional requirement

• ভেতরের যেকোনো সেবা একজন ব্যবহারকারী (বা একটি তালিকা) আর একটি template দিয়ে বার্তা পাঠাতে বলবে; প্ল্যাটফর্ম চারটি channel-এ পৌঁছাবে — মোবাইল push (ফোনের platform push service, যেমন Apple-এর APNs বা Google-এর FCM দিয়ে), SMS (SMS gateway বা aggregator দিয়ে), email আর অ্যাপের ভেতরের in-app inbox.
• দুই জাতের বার্তা: transactional (OTP, টাকা আসা-যাওয়া, টিকিট নিশ্চিত) আর promotional (অফার, প্রচার)। প্রথমটি দ্রুত আর নিশ্চিত, দ্বিতীয়টি ধীরে আর নিয়ম মেনে।
• ব্যবহারকারীর preference: কোন ধরনের বার্তা কোন channel-এ, ভাষা (বাংলা বা ইংরেজি), quiet hours, আর অফার বন্ধ করা (opt-out).
• নির্ধারিত সময়ে পাঠানো (campaign “সকাল ১০টায়, প্রত্যেকের নিজের সময়ে”), প্রতিটি বার্তার অবস্থা দেখা (queued, sent, delivered, failed) আর provider-এর প্রাপ্তিস্বীকার গ্রহণ।

Non-functional requirement

• OTP দ্রুত: API-তে আসা থেকে provider-এর গ্রহণ পর্যন্ত p99 ৫ সেকেন্ডের মধ্যে (ধরা যাক)। Provider থেকে ফোনে পৌঁছানো অপারেটরের হাতে — সেটি মাপব, কিন্তু প্রতিশ্রুতি দেব না।
• হারাবে না: API একবার 202 Accepted বললে বার্তাটি টেকসই জায়গায় আছে; transactional বার্তা নীরবে হারানো চলবে না। Duplicate যত কম সম্ভব।
• বিচ্ছিন্নতা: একটি দলের বিশাল campaign বা ভুল loop অন্য দলের OTP ধীর করবে না।
• Availability: API-র জন্য ৯৯.৯৫% (পর্ব ৫-এর nines-এর হিসাব)।
• খরচ আর গোপনীয়তা: SMS-এর বিল নজরে; ফোন নম্বর আর OTP-র কোড log-এ যাবে না।

ইন্টারভিউয়ার যে প্রশ্নগুলো শুনতে চান

বাংলাদেশের প্রেক্ষাপটে: অনেকে সবসময় মোবাইল ডেটা চালু রাখেন না, অনেকে feature phone ব্যবহার করেন, আর ব্যাংক ও mobile financial service-এর লেনদেনের খবর বা OTP-তে SMS এখনো খুব প্রচলিত (নির্দিষ্ট পরিসংখ্যান দাবি করছি না)। তাই “সব push-এ, SMS বাদ” নকশা সস্তা, কিন্তু অসম্পূর্ণ।

২ · হিসাব — কতগুলো বার্তা, কত দ্রুত, কত টাকা

পর্ব ৩-এর back-of-the-envelope হিসাব-এর নিয়মে সব ইনপুট আগে লিখে নিই, সবই “ধরা যাক”: দিনে ১ কোটি সক্রিয় ব্যবহারকারী; প্রত্যেকে দিনে গড়ে ৬টি push, ৪টি in-app, ০.৫টি email আর ০.১টি SMS পান। সবচেয়ে ব্যস্ত ঘণ্টা গড়ের ৩ গুণ (peak factor); তার ওপর একটি campaign ১০ মিনিটে ৫০ লাখ push পাঠায়। প্রতিটি worker সেকেন্ডে কতগুলো পাঠাতে পারে, সেটিও অনুমান — বাস্তবে load test করে মাপতে হয়। SMS-এর প্রতি টুকরোর দাম ধরা হলো ০.৩০ টাকা — এটি কাল্পনিক সংখ্যা, কোনো প্রদানকারীর দর নয়; আসল দাম চুক্তি, sender-এর ধরন আর সময়ভেদে আলাদা।

// Back-of-the-envelope for a fictional notification platform. Every input is an assumption.
const DAU = 10e6;                                            // daily active users
const perUser = { push: 6, inapp: 4, email: 0.5, sms: 0.1 }; // notifications per active user per day
const peakFactor = 3;                                        // busiest hour vs daily average
const blast = 5e6, blastMin = 10;                            // one promo push campaign in 10 minutes
const perWorker = { push: 500, inapp: 2000, email: 100, sms: 50 }; // sends/s per worker (assumed)
const util = 0.7;                                            // keep workers at most 70% busy
const fmt = n => Math.round(n).toLocaleString("en-US");
let total = 0;
console.log("channel   per day       avg/s   peak/s  workers");
for (const ch of Object.keys(perUser)) {
  const day = DAU * perUser[ch]; total += day;
  const avg = day / 86400;
  const peak = avg * peakFactor + (ch === "push" ? blast / (blastMin * 60) : 0);
  const workers = Math.max(2, Math.ceil(peak / (perWorker[ch] * util))); // min 2 for redundancy
  console.log(ch.padEnd(7) + fmt(day).padStart(12) + fmt(avg).padStart(10) +
    fmt(peak).padStart(9) + String(workers).padStart(9));
}
console.log("all channels: " + fmt(total) + " per day, " + fmt(total / 86400) + "/s on average");
// SMS cost: Bangla text needs Unicode (UCS-2): 70 chars in one SMS, 67 per part when longer.
const sms = DAU * perUser.sms, otpShare = 0.8;              // 80% OTP (1 part), 20% alerts (2 parts)
const parts = sms * otpShare * 1 + sms * (1 - otpShare) * 2;
const price = 0.30;                                          // taka per SMS part: ASSUMED, not a quote
console.log("SMS parts/day " + fmt(parts) + ", cost/day " + fmt(parts * price) +
  " taka, cost/30 days " + fmt(parts * price * 30) + " taka");
// Status log: one row per notification, ~400 bytes, kept 90 days, 3 replicas.
const bytes = total * 400 * 90 * 3;
console.log("status log for 90 days x3 replicas: " + (bytes / 1e12).toFixed(1) + " TB");

channel   per day       avg/s   peak/s  workers
push     60,000,000       694   10,417       30
inapp    40,000,000       463    1,389        2
email     5,000,000        58      174        3
sms       1,000,000        12       35        2
all channels: 106,000,000 per day, 1,227/s on average
SMS parts/day 1,200,000, cost/day 360,000 taka, cost/30 days 10,800,000 taka
status log for 90 days x3 replicas: 11.4 TB

টুকরোর হিসাবটি খেয়াল করুন। GSM-এর ৭-bit অক্ষরে একটি SMS-এ ১৬০টি অক্ষর ধরে, কিন্তু বাংলা লেখা Unicode (UCS-2)-এ যায়, তখন এক টুকরোয় মাত্র ৭০টি; লম্বা হলে প্রতিটি SMS segment-এ ৬৭টি। ১২০ অক্ষরের বাংলা সতর্কবার্তা তাই দুই টুকরো, একই দৈর্ঘ্যের ইংরেজি এক টুকরো; ইংরেজি লেখায় একটি বাংলা অক্ষর বা “বাঁকা” উদ্ধৃতিচিহ্ন ঢুকলেও পুরোটা Unicode-এ যেতে পারে। Template লেখার সময়েই দৈর্ঘ্য যাচাই (অংশ ৮) সরাসরি টাকা বাঁচায়। SMS-এর জন্মকথা Computer Networks কোর্সের মোবাইল নেটওয়ার্ক পর্বে।

৩ · API — একটি অনুরোধ, একটি key, বাকিটা প্ল্যাটফর্মের দায়

প্রধান API একটিই, আর সেটি asynchronous: প্ল্যাটফর্ম বার্তাটি টেকসইভাবে জমা নিয়ে সঙ্গে সঙ্গে 202 Accepted বলে; পাঠানো হয় পরে। ডাকা সেবা SMS provider-এর ধীরতায় আটকায় না। প্রতিটি অনুরোধে একটি idempotency key বাধ্যতামূলক (পর্ব ৮-এর REST API নকশা): network-এ উত্তর হারিয়ে ডাকা সেবা আবার পাঠালে একই key দেখে প্ল্যাটফর্ম আগের notification-এর id ফেরত দেয়, দ্বিতীয় SMS বানায় না।

POST /v1/notifications HTTP/1.1
Authorization: Bearer <service token of auth-service>
Idempotency-Key: login-otp-u42-7781
Content-Type: application/json

{ "recipient": { "user_id": "u42" },
  "category":  "auth.otp",            // decides priority, caps, quiet hours
  "channels":  ["sms"],
  "template":  "otp.login",
  "vars":      { "code": "482913" },  // secret: never logged
  "ttl_seconds": 300 }                // useless after 5 minutes

HTTP/1.1 202 Accepted
{ "notification_id": "n-9001", "status": "accepted" }

আরও কয়েকটি endpoint, ছোট করে:

• POST /v1/campaigns — template, audience-এর তালিকা বা segment-এর id, schedule: {"local_time": "10:00"}, সর্বোচ্চ হার; বড় campaign-এ দ্বিতীয় একজনের অনুমোদন লাগে।
• GET/PUT /v1/users/{id}/preferences — কোন বিষয় কোন channel-এ, ভাষা, time zone, quiet hours, opt-out.
• PUT /v1/users/{id}/devices — অ্যাপ চালু বা login হলে নিজের device token, platform আর ভাষা জানায়; logout-এ DELETE.
• GET /v1/notifications/{id} — অবস্থা আর প্রতিটি চেষ্টার ইতিহাস; GET /v1/users/{id}/inbox?cursor=… — in-app তালিকা, cursor pagination-এ।
• POST /hooks/{provider} — provider-দের delivery receipt আসার পথ; signature যাচাই ছাড়া কিছুই গৃহীত নয় (অংশ ৬)।

Key-এর নিয়ম পর্ব ৩৪-এর delivery semantics থেকে: key-এর পরিধি “কোন সেবা + key”, যাতে দুই দলের একই key সংঘাত না করে; একই key-তে ভিন্ন body এলে 422; আর key মনে রাখার সময়, অর্থাৎ dedup window, ২৪ ঘণ্টা — সবচেয়ে দেরিতে আসা retry-র চেয়ে লম্বা।

৪ · Data model — কোন তথ্য কোথায়, আর কেন

প্রতিটি তথ্যের পড়া-লেখার ধরন আলাদা, তাই store-ও আলাদা। নিয়মটি পর্ব ২০-এর SQL বনাম NoSQL আর পর্ব ২৩-এর partitioning থেকে: আগে access pattern, তারপর store আর partition key.

Delivery-র অবস্থা একটি ছোট state machine: accepted → queued → sending → sent → delivered, পাশে failed, expired, suppressed আর deferred. “sent” মানে provider গ্রহণ করেছে, “delivered” মানে provider জানিয়েছে ফোনে পৌঁছেছে — দুটি আলাদা রাখা জরুরি, কারণ মাঝখানে অনেক কিছু হারাতে পারে। Receipt আগে-পরে আসতে পারে, তাই নিয়ম: অবস্থা কেবল সামনে এগোয়, পেছনে ফেরে না (দেরিতে আসা “sent” একটি “delivered”-কে নামিয়ে দেবে না)।

Preference প্রতিটি বার্তায় পড়া হয় — দিনে ১০ কোটিবার — কিন্তু বদলায় কালেভদ্রে, তাই cache-এ রাখা হয়। শর্ত: opt-out-এর পরে পুরোনো কপি যেন অফার পাঠাতে না থাকে — লেখার সময় cache মোছা আর ছোট TTL (পর্ব ২৯-এর invalidation).

৫ · High-level design — producer থেকে ফোন, আর receipt ফিরে আসা

লেখার পথ: producer সেবা নিজের ডেটাবেসের transaction-এ ঘটনাটি outbox-এ লেখে, একটি relay সেটি API-তে পাঠায় (পর্ব ২৫-এর outbox pattern) — তাই “টাকা এল অথচ খবর গেল না” হয় না। API সেবার পরিচয় যাচাই করে (পর্ব ৫২-এর mTLS বা service token), key দেখে, প্রতিটি সেবার quota দেখে, তারপর একটি টেকসই ingest queue-তে লিখে 202 দেয়। Router preference আর template দেখে বার্তাটিকে এক বা একাধিক channel-এর লেনে পাঠায়; প্রতিটি লেন একটি আলাদা queue (পর্ব ৩১-এর message queue), যার পেছনে আলাদা worker pool. Worker provider-কে ডাকে, ফল লেখে।

পড়ার পথ হালকা: inbox খুললে user_id-এর partition থেকে সর্বশেষ বার্তা; অবস্থা দেখতে id ধরে খোঁজা। ফেরার পথ: provider-রা delivery receipt পাঠায় webhook-এ (পর্ব ৩২-এর webhook অংশ); সেগুলোও আগে queue-তে জমে, যাতে ঢল handler বসিয়ে না দেয়।

এবার একটি OTP-কে শুরু থেকে শেষ পর্যন্ত অনুসরণ করুন। Provider A ঠিক সেই মুহূর্তে অসুস্থ। “পরে” চাপুন:

৬ · Deep dive ক — নির্ভরযোগ্য delivery pipeline

পুরো pipeline at-least-once: প্রতিটি ধাপ নিশ্চিত হওয়ার পরেই পরের ধাপে ack দেয়, ব্যর্থ হলে আবার চেষ্টা করে। ফলে duplicate আসবে, আর প্রতিটি ধাপকে তা সইতে হবে — key দিয়ে API-তে, notification_id দিয়ে worker-এ আর status store-এ (পর্ব ৩৪)। চারটি জায়গায় নকশার সিদ্ধান্ত লাগে।

১. কোন ত্রুটিতে retry, কতবার, কতক্ষণ

Timeout, 5xx আর 429 (সাথে Retry-After) ক্ষণিকের — exponential backoff আর jitter-সহ আবার চেষ্টা। ভুল নম্বর, “এই token আর নেই” বা নিষিদ্ধ লেখা non-retryable — আবার চেষ্টা মানে শুধু টাকা নষ্ট। প্রতিটি বার্তার মেয়াদ (TTL) থাকে: ৫ মিনিট পরে OTP অর্থহীন, তাই retry নয়, expired. আর যে বার্তা প্রতিবার ব্যর্থ হবে (যেমন template-এ ভাঙা ভ্যারিয়েবল), তা কয়েকবার পরে DLQ-তে, ঠিক করার পরে redrive (পর্ব ৩১ আর পর্ব ৩৭-এর background job).

২. Provider failover আর circuit breaker — সংখ্যায়

দুটি SMS provider রাখা সাধারণ চর্চা, কিন্তু কীভাবে বদলাবেন? নিচের simulator-এ ১০ মিনিটে ২,০০০টি OTP; ১৮০ থেকে ৩৬০ সেকেন্ড পর্যন্ত A বিকল — প্রতিটি ডাক ৫ সেকেন্ডে timeout, আর তার ১০%-এ SMS আসলে চলে গিয়েছিল (অস্পষ্ট ফল)। বাকি সময়ে A-তে ২% আর B-তে ৩% ক্ষণিকের ত্রুটি। ৫% অনুরোধ producer নিজেই দুবার পাঠায় (একই key). প্রতিটি OTP-তে সর্বোচ্চ ৪টি চেষ্টা। তিনটি নীতি তুলনা করুন: শুধু A; প্রতিটি বার্তায় A আর B পালা করে; আর তার সাথে A-র জন্য একটি circuit breaker.

// 2,000 OTP SMS in 10 minutes. Provider A (primary) has an outage from 180 s to 360 s: calls time
// out after 5 s, and 10% of those timed-out SMS were actually sent (ambiguous). B is the backup.
function rng(seed) {                                   // mulberry32: seeded, repeatable
  return () => { seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
}
const g = rng(11), reqs = [];
for (let i = 0; i < 2000; i++) { const t = g() * 600; reqs.push({ key: "otp-" + i, t });
  if (g() < 0.05) reqs.push({ key: "otp-" + i, t: t + 1 + g() * 3 }); }   // producer retried: same key
reqs.sort((a, b) => a.t - b.t);
function run(policy) {
  const rand = rng(99), seen = new Set(), ttd = []; let blocked = 0, dup = 0, lost = 0, sick = 0, hist = [], openUntil = -1;
  const attempt = (p, t) => (p === "A" && t >= 180 && t < 360) ? (sick++, { dur: 5, ok: false, sent: rand() < 0.1 })
    : rand() < (p === "A" ? 0.02 : 0.03) ? { dur: 0.3, ok: false, sent: false }       // clear error
    : { dur: p === "A" ? 1.5 + rand() * 1.5 : 2 + rand() * 2, ok: true, sent: true };
  for (const r of reqs) {
    if (seen.has(r.key)) { blocked++; continue; } seen.add(r.key);  // idempotency key at the API
    let t = r.t, sends = 0, first = null; const startB = policy === "breaker" && t < openUntil;
    for (let k = 0; k < 4; k++) {                                   // at most 4 attempts
      const p = policy === "A only" ? "A" : ((k % 2 === 0) !== startB ? "A" : "B");
      const a = attempt(p, t);
      if (policy === "breaker" && p === "A" && k === 0) { hist = [...hist.slice(-9), a.ok];
        if (hist.filter(x => !x).length >= 5) { openUntil = t + 30; hist = []; } } // open for 30 s
      if (a.sent) { sends++; if (first === null) first = t + a.dur - r.t; }
      if (a.ok) break;
      t += a.dur + Math.pow(2, k) * (0.5 + rand() / 2);              // backoff 1,2,4 s with jitter
    }
    if (first === null) lost++; else ttd.push(first); if (sends > 1) dup++;
  }
  const s = ttd.sort((x, y) => x - y), q = p => s[Math.ceil(p * s.length) - 1].toFixed(1);
  console.log(policy.padEnd(12) + (100 * s.length / 2000).toFixed(1).padStart(7) + "%" +
    String(sick).padStart(7) + q(0.5).padStart(7) +
    q(0.99).padStart(7) + String(lost).padStart(6) + String(dup).padStart(6) + String(blocked).padStart(9));
}
console.log("policy        deliv. A-down    p50    p99  lost 2xSMS key-dups"); ["A only", "A<->B", "breaker"].forEach(run);

policy        deliv. A-down    p50    p99  lost 2xSMS key-dups
A only         83.7%   2205    2.4   25.3   327    46      101
A<->B         100.0%    605    2.6    9.9     0    59      101
breaker       100.0%     51    2.5    9.8     0     4      101

৩. Duplicate SMS — কোনটি সহনীয়, সিদ্ধান্ত লিখে রাখুন

পর্ব ৩৪-এ দেখেছেন, SMS বা সাধারণ email-এর মতো side effect আপনার transaction-এ বাঁধা যায় না; অনেক SMS provider আমাদের id নেয় কিন্তু সেই id দিয়ে duplicate আটকানোর নিশ্চয়তা দেয় কি না, তা প্রদানকারীভেদে আলাদা — চুক্তি আর documentation-এ যাচাই করুন। আর provider বদলালে কোনো key-ই কাজ করে না। তাই “exactly-once SMS” প্রতিশ্রুতি নয়; বরং প্রতিটি বিষয়ের জন্য সিদ্ধান্ত:

৪. Receipt — শেষ খবর, কিন্তু অসম্পূর্ণ

Receipt-এর webhook নিজেও at-least-once আর ক্রমহীন: একই DLR দুবার আসে, “delivered” আগে আর “sent” পরে আসে। তাই handler signature যাচাই করে (HMAC বা provider-এর নিয়মে), provider_msg_id দিয়ে খোঁজে আর শুধু সামনে এগোনো অবস্থা লেখে। কিছু receipt কখনো আসে না; নির্দিষ্ট সময় পরে অবস্থা “unknown”, অনুমানে “delivered” নয়। আর মাসশেষে provider-এর বিলের সাথে নিজের গণনা মেলানো (reconciliation). Push-এ provider শুধু গ্রহণের খবর দেয়; বাকিটা ভাবনার প্রশ্ন ৩-এ।

৭ · Deep dive খ — অগ্রাধিকার, ভিড় আর হারের নিয়ন্ত্রণ

সবচেয়ে বড় ঝুঁকি: ঈদের অফারের ১০ লাখ SMS আর কারও login-এর OTP একই লাইনে। Provider-রা মিলে সেকেন্ডে ১,০০০ SMS নেয় (ধরা যাক)। এক FIFO queue-তে সামনের ভিড় পেছনের সবাইকে আটকায় — head-of-line blocking. তিনটি নকশা: এক FIFO; একটি priority queue (একই worker, কিন্তু OTP আগে); আর bulkhead — OTP-র জন্য আলাদা queue আর সংরক্ষিত ১০০/s, বাকি ৯০০/s প্রচারের।

// OTP SMS mixed with a 1,000,000-message promo SMS blast. The SMS providers together accept
// 1,000 SMS/s (assumed). Compare one FIFO queue, a priority queue, and a bulkhead split.
function rng(seed) {                                   // mulberry32: seeded, repeatable
  return () => { seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
}
const rand = rng(57), C = 1000, otp = [], promo = [];
for (let t = 0; (t += -Math.log(1 - rand()) / 5) < 1200;) otp.push(t);        // ~5 OTP/s for 20 min
for (let i = 0; i < 1e6; i++) promo.push(i / 50000);                          // blast queued in 20 s
function serve(lanes, rate) {            // one server, strict priority by lane order, 1/rate s each
  const idx = lanes.map(() => 0), done = lanes.map(() => []), end = lanes.map(() => 0); let t = 0;
  while (lanes.some((l, k) => idx[k] < l.length)) {
    let k = lanes.findIndex((l, j) => idx[j] < l.length && l[idx[j]] <= t);
    if (k < 0) { t = Math.min(...lanes.map((l, j) => idx[j] < l.length ? l[idx[j]] : Infinity)); continue; }
    t += 1 / rate; done[k].push(t - lanes[k][idx[k]++]); end[k] = t;
  }
  return [done, end];
}
const pct = (a, p) => { const s = [...a].sort((x, y) => x - y); return s[Math.ceil(p * s.length) - 1]; };
const show = (name, w, promoEnd) => console.log(name.padEnd(22) + (pct(w, 0.5)).toFixed(3).padStart(9) +
  (pct(w, 0.99)).toFixed(3).padStart(10) + String(w.filter(x => x > 120).length).padStart(8) +
  String(Math.round(promoEnd)).padStart(9));
const fifo = [...otp.map(t => [t, 0]), ...promo.map(t => [t, 1])].sort((a, b) => a[0] - b[0]);
let t = 0; const fOtp = []; let fEnd = 0;
for (const [a, k] of fifo) { t = Math.max(t, a) + 1 / C; if (k === 0) fOtp.push(t - a); else fEnd = t; }
console.log("OTP count " + otp.length + ", promo 1000000, capacity " + C + " SMS/s");
console.log("mode                  OTP p50   OTP p99  >120 s  promo done (s)");
show("one FIFO queue", fOtp, fEnd);
const [[pO], pEnd] = serve([otp, promo], C);
show("priority queue", pO, pEnd[1]);
const [[bO]] = serve([otp], 100), [, [bEnd]] = serve([promo], 900);           // 100 + 900 = 1000
show("bulkhead 100 + 900", bO, bEnd);

OTP count 5975, promo 1000000, capacity 1000 SMS/s
mode                  OTP p50   OTP p99  >120 s  promo done (s)
one FIFO queue          409.702   967.375    4376     1000
priority queue            0.001     0.002       0     1005
bulkhead 100 + 900        0.010     0.018       0     1111

তাহলে priority queue-ই সেরা? পুরোপুরি না। Strict priority-তে উঁচু লেন কখনো ফাঁকা না হলে নিচু লেন আটকে থাকে — starvation (Operating Systems কোর্সের Priority scheduling পর্বে aging-সহ)। আর একই worker আর connection pool ভাগ করলে প্রচারের worker-দের crash OTP-কেও ধরে। তাই বাস্তবে লেনভেদে আলাদা queue আর worker pool (bulkhead, পর্ব ৪৮), লেনের ভেতরে প্রয়োজনে অগ্রাধিকার। অনেক দেশে transactional আর promotional SMS-এর আলাদা পথ বা sender-এর ধরন থাকে (বাংলাদেশে “masking” আর “non-masking” sender-এর কথা প্রায়ই শোনা যায়; নিয়ম সময়ভেদে বদলায়, যাচাই করুন) — তাতে bulkhead provider পর্যন্ত পৌঁছায়।

হারের চারটি সীমা

• Provider-এর সীমা: চুক্তির হার; সব worker মিলে একটি ভাগ করা token bucket (পর্ব ৪৯-এর distributed limiter); 429 এলে AIMD-এর মতো হার অর্ধেক, তারপর ধীরে বাড়ানো। Queue জমলে campaign-এর batch তৈরি থামে — backpressure (পর্ব ১৮-এর overload).
• প্রতিটি দলের সীমা: প্রতিটি tenant একটি quota পায়, যাতে এক দলের ভুল loop বাকিদের জন্য noisy neighbor না হয়।
• প্রতিটি ব্যবহারকারীর সীমা: দিনে সর্বোচ্চ ৩টি অ-জরুরি বার্তা — frequency cap (অংশ ৮)।
• প্রতিটি ফোন নম্বরের OTP-সীমা: খরচ আর অপব্যবহার ঠেকাতে (অংশ ৯)।

নির্ধারিত সময় আর time zone

“সকাল ১০টায়” মানে কার সকাল? ঢাকার ১০টা UTC+3-এর দেশগুলোতে (মধ্যপ্রাচ্যের কয়েকটি দেশ) সকাল ৭টা। তাই campaign সময়-অঞ্চল ধরে ভাগ হয়, প্রতিটি ভাগ একটি delayed job (পর্ব ৩৭)। আর হার সীমিত রাখা লাখো মানুষের একসাথে অ্যাপ খোলার thundering herd-কেও কয়েক মিনিটে ছড়িয়ে দেয় (ভাবনার প্রশ্ন ৪)।

৮ · Deep dive গ — preference, template আর device token

Preference, opt-out আর quiet hours

Preference-এর মডেল একটি ছক: বিষয় (OTP, লেনদেন, অর্ডার, অফার, সামাজিক) × channel. কিছু বিষয় বন্ধ করা যায় না (OTP, নিরাপত্তার সতর্কতা); বাকিগুলো ব্যবহারকারীর হাতে। Opt-out দ্রুত কার্যকর হতে হবে, আর কখন, কোন পথে (অ্যাপের সেটিং, email-এর unsubscribe link, SMS-এর keyword) এল তার audit সারি থাকবে — খুঁটিনাটি আইন দেশভেদে আলাদা, তাই নিয়ম config-এ, আইনি দলের সাথে মিলিয়ে। Email-এ বারবার ফেরত আসা ঠিকানা (hard bounce) বা “spam” বলে চিহ্নিত করা মানুষ একটি suppression list-এ যান; সেখানে আবার পাঠালে প্রেরকের সুনাম নষ্ট হয় আর ভালো বার্তাও spam-এ যায় (বড় mailbox প্রদানকারীদের প্রেরক-নিয়ম Computer Networks কোর্সের ইমেইল পর্বের অংশ ৮-এ)।

Quiet hours (ধরা যাক রাত ১০টা থেকে সকাল ৮টা) ব্যবহারকারীর নিজের time zone-এ হিসাব করতে হয়, সার্ভারের ঘড়িতে নয়। নিচের simulator একটি দিনের ৩,০০০টি ঘটনা ৩০০ জনের ওপর চালায়, নিয়মগুলো এই ক্রমে: transactional সবসময় যায়; অফারে opt-out; একই template ৬ ঘণ্টার মধ্যে দ্বিতীয়বার হলে duplicate; quiet hours-এ পিছিয়ে; দিনে ৩টির বেশি অ-জরুরি নয়।

// One day of 3,000 notification events for 300 users. Rules, checked in this order:
// transactional (otp, payment) always go; promo opt-out; same template within 6 h = duplicate;
// quiet hours 22:00-08:00 in the USER's time zone = defer to 08:00; cap 3 non-transactional per day.
function rng(seed) {                                   // mulberry32: seeded, repeatable
  return () => { seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
}
const rand = rng(2026), users = [];
for (let u = 0; u < 300; u++) { const r = rand();
  users.push({ tz: r < 0.85 ? 6 : r < 0.95 ? 3 : 0, optOutPromo: rand() < 0.15, sent: 0, last: {} }); }
const types = [["otp", 0.15], ["payment", 0.15], ["reminder", 0.3], ["promo", 0.4]];
const ev = Array.from({ length: 3000 }, () => {
  let r = rand(), k = 0; while (r > types[k][1]) r -= types[k++][1];
  const type = types[k][0], tpl = type === "promo" ? "promo-" + Math.floor(rand() * 3) : type;
  return { t: rand() * 24, u: Math.floor(rand() * 300), type, tpl };     // t = hour of day in UTC
}).sort((a, b) => a.t - b.t);
const out = {}, add = (type, why) => { const k = type + " / " + why; out[k] = (out[k] || 0) + 1; };
for (const e of ev) {
  const u = users[e.u], local = (e.t + u.tz) % 24;
  if (e.type === "otp" || e.type === "payment") { add(e.type, "sent"); continue; }
  if (e.type === "promo" && u.optOutPromo) { add(e.type, "suppressed: opted out"); continue; }
  if (u.last[e.tpl] !== undefined && e.t - u.last[e.tpl] < 6) { add(e.type, "suppressed: duplicate"); continue; }
  if (local >= 22 || local < 8) { add(e.type, "deferred: quiet hours"); continue; }
  if (u.sent >= 3) { add(e.type, "suppressed: daily cap"); continue; }
  u.sent++; u.last[e.tpl] = e.t; add(e.type, "sent");
}
let tot = { sent: 0, suppressed: 0, deferred: 0 };
for (const k of Object.keys(out).sort()) { console.log(k.padEnd(34) + String(out[k]).padStart(5));
  tot[k.split(" / ")[1].split(":")[0]] += out[k]; }
console.log("total: sent " + tot.sent + ", suppressed " + tot.suppressed + ", deferred " + tot.deferred);
const quiet = h => h >= 22 || h < 8, nonTx = ev.filter(e => e.type === "promo" || e.type === "reminder");
const wrong = nonTx.filter(e => !quiet((e.t + 6) % 24) && quiet((e.t + users[e.u].tz) % 24)).length;
console.log("if quiet hours used server time (UTC+6): " + wrong + " events would reach users abroad at night");

otp / sent                          484
payment / sent                      476
promo / deferred: quiet hours       388
promo / sent                        400
promo / suppressed: daily cap        68
promo / suppressed: duplicate       134
promo / suppressed: opted out       185
reminder / deferred: quiet hours    331
reminder / sent                     291
reminder / suppressed: daily cap     52
reminder / suppressed: duplicate    191
total: sent 1651, suppressed 630, deferred 719
if quiet hours used server time (UTC+6): 54 events would reach users abroad at night

Template আর localization

Template আলাদা সেবায় থাকে, কোডে নয়: প্রতিটি template-এর id, version, ভাষা (bn, en) আর channel-ভেদে রূপ — push-এ শিরোনাম ও ছোট লেখা, SMS-এ ৭০ অক্ষরের মধ্যে, email-এ HTML আর সাধারণ লেখা দুটোই। Localization শুধু অনুবাদ নয়: টাকার চিহ্ন (৳৫০০), বাংলা অঙ্ক, তারিখের রূপ আর ভাষা না পেলে কোনটিতে ফিরবে (bn → en). প্রকাশের আগে স্বয়ংক্রিয় যাচাই: সব ভ্যারিয়েবল আছে কি না, SMS কয় টুকরো, link নিরাপদ কি না। ভ্যারিয়েবলের মান (যেমন প্রেরকের নাম) ব্যবহারকারীর লেখা হতে পারে, তাই HTML-এ escape আর SMS-এ link ছাঁটা — নইলে কেউ নিজের নামে প্রতারণার link বসিয়ে আপনার প্ল্যাটফর্ম দিয়েই ছড়াবে। প্রতিটি বার্তায় template-এর version লেখা থাকে।

Device token-এর জীবনচক্র

অ্যাপ চালু বা login হলে token নিয়ে PUT /devices-এ জানায়; token বদলালে আবার। একজনের কয়েকটি ফোন, তাই কয়েকটি token. Logout-এ token মুছতে হয়, নইলে পুরোনো ফোনে নতুন মালিকের খবর যেতে পারে। Provider token-কে অবৈধ বললে (APNs-এ 410 Unregistered, FCM-এ UNREGISTERED — লেখার সময়ের documentation অনুযায়ী) সঙ্গে সঙ্গে মোছা, আর অনেকদিন দেখা না যাওয়া token নিয়মিত ছাঁটাই।

৯ · ভাঙন, trade-off আর বিস্তার

কোনটি মরলে কী হয়

১০ গুণ বড় হলে

দিনে ১০০ কোটি বার্তা আর ৫ কোটির campaign হলে push worker ৩০ থেকে প্রায় ৩০০, status store-এ দিনে প্রায় ৪২০ GB নতুন লেখা (এক কপিতে, অংশ ২-এর ৪০০ byte ধরে) — partition আর TTL ছাড়া চলে না, queue-র partition বাড়ে (পর্ব ৩৩-এর log-ভিত্তিক streaming). কিন্তু প্রথম দেয়াল আমাদের সার্ভার নয়, provider-এর সীমা আর বিল: বেশি account আর হার, আর কম SMS — push আগে, না খোলা হলে তবেই SMS (OTP ছাড়া), অ-জরুরি বার্তা দিনে একবার সারাংশে। ব্যবহারকারীদের আলাদা cell-এ ভাগ করাও একটি পথ (পর্ব ৪৮)।

অপব্যবহার — শুধু প্রতিরক্ষা

“OTP পাঠান” বোতাম এমন একটি দরজা, যা চাপলেই আপনার টাকা খরচ হয়। SMS pumping-এ স্বয়ংক্রিয় অনুরোধে বিপুল OTP পাঠানো হয়, বিল ওঠে আপনার নামে। প্রতিরক্ষা কয়েক স্তরে: প্রতি নম্বর, device, IP আর নম্বর-সীমায় (prefix) হারের সীমা; সন্দেহজনক অনুরোধে বাড়তি যাচাই; আর সবচেয়ে কাজের সংকেত — “OTP চাওয়া” বনাম “সফল login”-এর অনুপাত, যা হঠাৎ পড়লে সতর্কবার্তা। দৈনিক SMS বাজেট ছাড়ালে নতুন অঞ্চলে পাঠানো থামানো (পর্ব ৪৯ আর ৫২-এর প্রয়োগ)।

কী মাপবেন আর কখন জাগাবেন

প্রতিটি channel আর লেনের আলাদা SLI (পর্ব ৫০-এর observability): API-র latency; প্রতিটি queue-র সবচেয়ে পুরোনো বার্তার বয়স (শুধু queue depth নয় — ১০ লাখের queue স্বাভাবিক, ১০ মিনিট পুরোনো OTP নয়); provider-ভেদে গ্রহণ আর delivered-এর হার; OTP-র সফল যাচাইয়ের অনুপাত; campaign-এর পরে opt-out; আর SMS-এর খরচ। SLO ধরা যাক: “৩০ দিনে ৯৯% OTP ৫ সেকেন্ডের মধ্যে provider-এ গৃহীত”; alert burn rate দিয়ে। Log-এ ফোন নম্বর আর কোড নয় — PII মুখোশে।

১০ · AI-এর যুগে — notification-এর নকশা যাচাই

AI-কে একটি notification system-এর নকশা চাইলে প্রায়ই একটি সুন্দর ছবি আসে: Kafka, Redis, কয়েকটি microservice, FCM আর একটি SMS API. দেখতে পূর্ণ, কিন্তু এই case-এর কঠিন অংশগুলো — অগ্রাধিকারের বিচ্ছিন্নতা, provider বদলের duplicate, time zone আর SMS-এর খরচ — প্রায়ই অনুপস্থিত। সাধারণ ভুলগুলো:

AI-এর নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• OTP আর প্রচারের লেন আলাদা কি না, আর campaign চলাকালীন OTP-র latency simulator বা ছোট load test-এ মেপেছি
• Worker সংখ্যা, peak আর SMS-এর টুকরো ও খরচের অঙ্ক নিজে আবার করেছি
• Provider-এর হার, payload আর token-এর ত্রুটির নাম অফিসিয়াল documentation-এ মিলিয়েছি
• অস্পষ্ট timeout, receipt না আসা আর provider পুরো বিকল — তিনটির উত্তর লিখিত আছে
• Time zone, quiet hours, opt-out-এর audit আর token ছাঁটাই নকশায় আছে
• নকশাটি প্রয়োজনের চেয়ে বড় নয় — প্রতিটি অংশের কারণ বলতে পারি