Case study: chat আর messaging system — delivery, ordering আর presence

১ · সমস্যা আর পরিধি — কী বানাচ্ছি, কী বানাচ্ছি না

রিনা ঢাকায় অফিসে, বাবা-মা রাজশাহীতে, ভাই তানভীর চট্টগ্রামের ট্রেনে। পরিবারের group-এ রিনা লিখলেন “আসছি”. তানভীরের ফোনে নেটওয়ার্ক এই আছে, এই নেই; ল্যাপটপটি বাসায় চালু। কয়েক সেকেন্ড পর রিনার পর্দায় দুটি টিক, বিকেলে নীল। এই সাধারণ অভিজ্ঞতার পেছনের সিস্টেমটিই এই পর্বের বিষয়। আমরা একটি chat অ্যাপ নকশা করব — নাম ধরা যাক “আলাপ” (কাল্পনিক); কোনো বাস্তব প্রতিষ্ঠানের নকশা এটি নয়।

Module ৯-এর প্রতিটি case study আগের ৫৩টি পর্বের টুকরো জোড়া দেয়। কোনো ধারণা আবার শেখানো হবে না; প্রতিটির এক বাক্যের প্রয়োগ আর সেই পর্বের লিংক থাকবে। ক্রমটি পর্ব ০৬-এর আট ধাপের: পরিধি, হিসাব, API, data model, ছবি, গভীরে নামা, ভাঙন আর গুছিয়ে শেষ।

Functional requirement — অ্যাপটি কী করবে

• 1:1 আর group chat — group-এ সর্বোচ্চ ৫০০ সদস্য (ধরা যাক)। লেখা, ছবি, ভয়েস নোট; বড় ফাইল যায় object storage-এ, বার্তায় থাকে শুধু তার pointer.
• তিন অবস্থার টিক — sent (server জমা নিয়েছে), delivered (প্রাপকের অন্তত একটি ডিভাইসে পৌঁছেছে), read (প্রাপক খুলে দেখেছেন)।
• Presence আর last seen — কে অনলাইন, কে শেষ কখন ছিলেন; গোপনীয়তার সেটিং মেনে।
• Multi-device — একজনের ফোন, ল্যাপটপ, ট্যাব; সব ডিভাইসে একই কথোপকথন, একই ক্রমে।
• Offline delivery — প্রাপক অফলাইন থাকলে বার্তা জমা থাকে, ফিরলে পৌঁছায়; ফোনে push notification যায়।

Non-functional requirement — কতটা ভালোভাবে

• Durability: server যে বার্তায় “sent” দিয়েছে, তা কখনো হারাবে না। এটিই সবচেয়ে কড়া শর্ত (পর্ব ০২)।
• ক্রম: একটি কথোপকথনের ভেতরে সব সদস্য আর সব ডিভাইস একই ক্রম দেখবে। দুটি আলাদা কথোপকথনের মধ্যে ক্রমের দাবি নেই।
• Latency: দুজনই অনলাইন থাকলে বার্তা পৌঁছাবে মোটামুটি এক সেকেন্ডের কম সময়ে, p99 লক্ষ্য ধরা যাক ৫০০ ms (পর্ব ০৪)।
• দুর্বল নেটওয়ার্ক: বাংলাদেশে অনেকেই মূলত মোবাইল ডেটায় ইন্টারনেট ব্যবহার করেন, আর লিফট, ট্রেন বা লোডশেডিংয়ে সংযোগ কেটে যাওয়া পরিচিত ঘটনা। কোনো পরিসংখ্যান না ধরে আমরা এটিকেই স্বাভাবিক অবস্থা ধরি: সংযোগ ভাঙবেই, বার্তা হারাবে না, ব্যাটারি আর ডেটা কম খরচ হবে।
• Availability: বছরে কয়েক ঘণ্টার বেশি বন্ধ নয় (পর্ব ০৫); কোনো অংশ বসে গেলেও বার্তা পাঠানো চালু থাকা চাই, presence-এর মতো বাড়তি সুবিধা আগে বাদ যাবে।

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

২ · হিসাব — বার্তা, সংযোগ, gateway আর storage

পর্ব ০৩-এর chat উদাহরণের ধারাবাহিকতায় একই ভিত্তি ধরি: ৫ কোটি DAU, প্রত্যেকে দিনে ৪০টি বার্তা, ২০০ byte, peak factor ৫। এবার যোগ হলো group, ডিভাইস, সংযোগ আর media. প্রতিটি সংখ্যা “ধরা যাক”; একটি বদলে আবার চালিয়ে দেখুন।

// Chat estimator. Every input is an assumption (ধরা যাক): change one and run again.
const DAU = 50e6;            // daily active users
const MSG_PER_USER = 40;     // messages each user sends per day
const PEAK = 5;              // peak hour vs average
const GROUP_SHARE = 0.3, GROUP_RECIP = 25;  // 30% go to groups; avg 25 other members
const DEVICES = 1.4;         // devices per recipient that must receive a copy
const ONLINE = 0.2;          // share of DAU connected at the peak moment
const PER_GW = 100000;       // our cap of connections per gateway (blast radius)
const ZONES = 3;             // must survive losing one zone
const BYTES = 200, REPL = 3; // text + metadata per message; copies in the store
const MEDIA_SHARE = 0.05, MEDIA_KB = 200;   // 5% carry a photo/voice note, avg 200 KB

const perDay = DAU * MSG_PER_USER, avg = perDay / 86400, peak = avg * PEAK;
const recipients = (1 - GROUP_SHARE) * 1 + GROUP_SHARE * GROUP_RECIP;
const deliveries = peak * recipients * DEVICES;     // copies pushed to devices per second
const receipts = peak * recipients * 2;             // delivered + read, per recipient user
const conns = DAU * ONLINE * DEVICES;
const gws = Math.ceil(conns / PER_GW), gwsSafe = Math.ceil(gws / (ZONES - 1)) * ZONES;
const textTB = perDay * BYTES * 365 * REPL / 1e12;
const mediaPB = perDay * MEDIA_SHARE * MEDIA_KB * 1e3 * 365 / 1e15;
const f = (x) => Math.round(x).toLocaleString("en-US");
console.log("messages/day        " + f(perDay));
console.log("avg msg/s           " + f(avg));
console.log("peak msg/s (writes) " + f(peak));
console.log("recipients/message  " + recipients.toFixed(1));
console.log("peak deliveries/s   " + f(deliveries));
console.log("peak receipts/s     " + f(receipts));
console.log("connections at peak " + f(conns));
console.log("gateways (cap " + f(PER_GW) + ") " + gws + ", zone-safe " + gwsSafe);
console.log("text, 1 year x" + REPL + "   " + textTB.toFixed(1) + " TB");
console.log("media, 1 year       " + mediaPB.toFixed(2) + " PB (object storage, before its own redundancy)");

messages/day        2,000,000,000
avg msg/s           23,148
peak msg/s (writes) 115,741
recipients/message  8.2
peak deliveries/s   1,328,704
peak receipts/s     1,898,148
connections at peak 14,000,000
gateways (cap 100,000) 140, zone-safe 210
text, 1 year x3   438.0 TB
media, 1 year       7.30 PB (object storage, before its own redundancy)

সংখ্যাগুলো থেকে চারটি নকশা-সিদ্ধান্ত সরাসরি বেরিয়ে আসে:

1. লেখা-ভারী, append-only: বার্তা লেখা হয় একবার, বদলায় প্রায় কখনো না, পড়া হয় সাম্প্রতিকগুলোই। এমন কাজের জন্য LSM-tree-ভিত্তিক store মানানসই (পর্ব ১৯)।
2. Gateway গোনা হয় সংযোগে: ১.৪ কোটি সংযোগ ধরে রাখাই মূল কাজ; বার্তার সংখ্যা তুলনায় ছোট।
3. Receipt-কে সস্তা করতে হবে: প্রতিটি বার্তার আলাদা read receipt না পাঠিয়ে “৫৮ পর্যন্ত পড়েছি” — একটি সংখ্যা অনেক বার্তা ঢেকে দেয়। ১৮ লাখ সংখ্যাটি তাই ঊর্ধ্বসীমা।
4. Media আলাদা পথে: ছবি chat service-এর ভেতর দিয়ে যাবে না; ফোন সরাসরি object storage-এ তোলে, বার্তায় যায় শুধু key (পর্ব ২৬), আর পড়া হয় CDN থেকে (পর্ব ১৭)।

৩ · API — WebSocket-এর বার্তা-খাম, REST-এর পথ আর idempotent send

অনলাইন থাকার সময় ফোন আর server-এর মাঝে একটি WebSocket সংযোগ খোলা থাকে; দুই দিক থেকেই যেকোনো সময় ছোট frame যায় (পর্ব ১০)। Frame-এর ভেতরের রূপ JSON না Protobuf, সেটি পর্ব ১২-এর প্রশ্ন; মোবাইল ডেটা বাঁচাতে binary রূপ লাভজনক। নিচে বোঝার জন্য JSON:

→ {"t":"send", "conv":"c42", "cid":"r-901", "body":"<ciphertext>", "media":null}
← {"t":"ack",  "cid":"r-901", "seq":1207, "ts":"2026-10-28T09:14:03Z"}
← {"t":"msg",  "conv":"c42", "seq":1207, "from":"u17/d1", "body":"<ciphertext>"}
→ {"t":"rcpt", "conv":"c42", "delivered_upto":1207}
→ {"t":"rcpt", "conv":"c42", "read_upto":1207}
→ {"t":"sync", "cursors":{"c42":1207, "c77":88}}
← {"t":"sync_page", "conv":"c42", "msgs":[...], "next_after":1215, "more":false}
→ {"t":"ping"}   ← {"t":"pong"}

সবচেয়ে গুরুত্বপূর্ণ field হলো cid — ফোনের নিজের বানানো অনন্য id. বার্তা পাঠানোর আগেই ফোন তাকে নিজের local outbox-এ লেখে, পর্দায় দেখায় ঘড়ির চিহ্ন। Ack না এলে একই cid দিয়ে আবার পাঠায়। Server (conv, sender_device, cid)-এ unique নিয়ম রাখে; একই cid আবার এলে নতুন বার্তা না বানিয়ে আগের seq-টাই ফেরত দেয়। এটি REST-এর idempotency key-এর হুবহু ভাবনা (পর্ব ০৮), শুধু WebSocket-এর ওপরে।

যে কাজগুলো স্থায়ী সংযোগে মানায় না, সেগুলো সাধারণ HTTPS-এ যায়:

POST /v1/media/uploads            {"size": 184320, "type": "image/jpeg"}
  → 201 {"media_key": "m/7f3a…", "upload_url": "<presigned URL, 15 min>"}
GET  /v1/conversations/c42/messages?before_seq=1150&limit=50
  → 200 {"msgs": [...], "next_before": 1100}

প্রথমটি ফোনকে একটি presigned URL দেয়, যাতে ছবি সরাসরি object storage-এ ওঠে। দ্বিতীয়টি পুরোনো ইতিহাস পাতা ধরে আনে — seq-ভিত্তিক keyset pagination, offset নয়, কারণ নতুন বার্তা ঢুকলেও পাতা সরে না।

৪ · Data model — conversation log, partition key আর ডিভাইসের cursor

প্রতিটি table-এর key ঠিক হয় তার প্রশ্ন দেখে (পর্ব ২০)। আমাদের প্রধান প্রশ্নগুলো: c42-এর ১২০৭-এর পরের বার্তাগুলো কী, আমার chat তালিকায় কী কী, আর এই ডিভাইস কোথা পর্যন্ত পেয়েছে।

Message table-এর partition key হলো conversation; ফলে একটি কথোপকথনের সব বার্তা এক জায়গায়, seq-এর ক্রমে সাজানো (clustering key). খুব পুরোনো বা ব্যস্ত কথোপকথন সীমাহীন বড় না হতে bucket — একটি সময়ের জানালা — যোগ হয়েছে; এই পুরো যুক্তি আর CQL উদাহরণ পর্ব ২৩-এ আছে। বাকি থাকে প্রশ্নটি: seq দেবে কে?

৫০০ সদস্যের সীমা এখানেও কাজ করে: একটি group-এ সেকেন্ডে বড়জোর কয়েক ডজন বার্তা আসে, তাই এক লেখকেই কুলোয়। লাখো সদস্যের channel হলে এই হিসাব ভাঙত — সেজন্যই সেটি পরিধির বাইরে।

৫ · High-level design — ছবি আর একটি বার্তার পুরো পথ

লেখার পথ: ফোন → load balancer → একটি gateway → chat service (c42-এর মালিক) → dedup আর seq → message store-এ টেকসই লেখা (পর্ব ২২-এর replica-সহ) → তারপরেই ack. আগে ack দিয়ে পরে লেখা ব্যর্থ হলে “sent” বার্তা হারাত — durability-র শর্ত ভাঙত। পৌঁছানোর পথ: chat service সদস্যদের ডিভাইস খোঁজে connection registry-তে, তারপর সংশ্লিষ্ট gateway-গুলোকে পাঠায়; অফলাইন ডিভাইসের জন্য push. পড়ার পথ: ফোন নিজের cursor জানিয়ে বাকিটা চায়। এর সাধারণ রূপ পর্ব ১০-এর stepper-এ দেখেছেন; এবার দুই ডিভাইস আর তিন টিক যোগ করে দেখি। “পরে” চাপুন:

৬ · Deep dive ১ — লাখো সংযোগ: gateway, registry, heartbeat আর reconnect storm

Gateway পাতলা রাখা। প্রতিটি gateway শুধু TLS শেষ করে, পরিচয় যাচাই করে, heartbeat দেখে আর socket-এ লেখে। ব্যবসার কোনো যুক্তি এখানে নেই; ফলে gateway বদলানো, বাড়ানো বা মারা সহজ। যে state আছে — কোন socket কার — তা হারালে client আবার সংযোগ নিলেই আবার গড়ে ওঠে (পর্ব ১৫)। দীর্ঘজীবী সংযোগে load balancer-এর least-connections বা ভারসাম্যের সমস্যা আর deploy-এর সময় connection draining পর্ব ১০, পর্ব ১৪ আর পর্ব ৫৩-এ আছে।

Registry. সংযোগ খুললেই gateway লেখে “device d1 → G5”, TTL ধরা যাক ৯০ সেকেন্ড, আর প্রতিটি heartbeat-এ নবায়ন করে। Gateway নিঃশব্দে মরলে entry নিজে থেকেই মুছে যায়, chat service তখন ডিভাইসটিকে অফলাইন ধরে push পাঠায়। Registry হারালেও বিপদ কম: প্রতিটি gateway নিজের সংযোগের তালিকা আবার লিখে দেয়। এটি “cache, সত্যের উৎস নয়” — সত্য থাকে message store আর cursor-এ।

Heartbeat-এর ব্যবধান। মোবাইল অপারেটরের CGNAT অনেকক্ষণ নীরব সংযোগের mapping ভুলে যেতে পারে; তখন server ভাবে সংযোগ আছে, অথচ বার্তা পৌঁছায় না (Computer Networks · NAT). ঘন heartbeat এটি ঠেকায়, কিন্তু প্রতিবার ফোনের radio জাগে — tail energy-র খরচ (পর্ব ১০)। তাই ব্যবধান মাপা হয় বাস্তব নেটওয়ার্কে, আর অ্যাপ পেছনে গেলে স্থায়ী সংযোগ ছেড়ে platform push-এর ওপর ভরসা করা হয়।

এক gateway-তে কত? RAM-এ হয়তো কয়েক লাখ সংযোগ আঁটে, কিন্তু আমরা সীমা রেখেছি ১ লাখ। কারণ একটি gateway মরলে তার সব client একসাথে ফিরবে; সেই ভিড়ই তার blast radius. সরল রাখতে ধরা যাক একটি cell-এ ১০টি gateway; তার একটি, G0, যাতে ৫০ হাজার সংযোগ, হঠাৎ crash করল, আর load balancer তার client-দের ওই cell-এর বাকি ৯টিতে পাঠায়। প্রতিটি সেকেন্ডে বড়জোর ২,০০০টি নতুন handshake শেষ করতে পারে, আর প্রত্যাখ্যাত চেষ্টাও একটি handshake-এর ১০% CPU খায় — সব ধরা যাক। চারটি client-কৌশল তুলনা করি (পর্ব ৪৮-এর backoff আর jitter):

// Gateway G0 (50,000 connections) dies at t = 0. Its clients reconnect through the load
// balancer to the 9 surviving gateways. ধরা যাক: each gateway can finish 2,000 new
// handshakes per second; a refused attempt still burns 10% of a handshake's CPU.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const C = 50000, GW = 9, CAP = 2000, REFUSE = 0.1, CAP_S = 32;
function storm(name, firstDelay, backoff) {
  const rnd = mulberry32(48);
  let wait = Array.from({ length: C }, () => [firstDelay(rnd), 0]);   // [next try time, failures]
  let peak = 0, tries = 0, t = 0, done = 0, t99 = null;
  for (; wait.length && t < 300; t++) {
    const now = wait.filter(w => w[0] < t + 1), later = wait.filter(w => w[0] >= t + 1);
    const load = new Array(GW).fill(0), next = [];
    const byGw = Array.from({ length: GW }, () => []);
    for (const w of now) byGw[Math.floor(rnd() * GW)].push(w);   // load balancer: random survivor
    byGw.forEach((list, g) => { const A = list.length; load[g] = A; tries += A;
      const ok = A <= CAP ? A : Math.max(0, Math.floor((CAP - REFUSE * A) / (1 - REFUSE)));
      done += ok; for (const w of list.slice(ok)) next.push([t + 1 + backoff(rnd, w[1]), w[1] + 1]); });
    peak = Math.max(peak, ...load); wait = later.concat(next);
    if (t99 === null && done >= 0.99 * C) t99 = t + 1;
  }
  console.log(name.padEnd(28) + String(peak).padStart(6) + String(tries - C).padStart(9) +
    String(t99).padStart(7) + " s");
}
console.log("strategy (cap " + CAP + "/s/gw)    peak  refused  99% back");
storm("retry every 1 s", () => 0, () => 0);
storm("exp backoff, no jitter", () => 0, (r, k) => Math.min(CAP_S, 2 ** k) - 1);
storm("full jitter", () => 0, (r, k) => r() * Math.min(CAP_S, 2 ** k));
storm("spread 0-5 s + full jitter", (r) => r() * 5, (r, k) => r() * Math.min(CAP_S, 2 ** k));

strategy (cap 2000/s/gw)    peak  refused  99% back
retry every 1 s               5632    56760      4 s
exp backoff, no jitter        5632    56760      8 s
full jitter                   5632    55074      4 s
spread 0-5 s + full jitter    1160        0      5 s

ন্যূনতম ছড়ানোর জানালা হিসাব করা যায়: ৫০,০০০ ÷ (৯ × ২,০০০) ≈ ২.৮ সেকেন্ড। এর কম হলে প্রত্যাখ্যান হবেই (অনুশীলন ৪)। Gateway process crash করলে TCP সংযোগ সঙ্গে সঙ্গে ভাঙে, তাই সবাই একই মুহূর্তে টের পায়; যন্ত্রটি নিঃশব্দে হারালে heartbeat-এর timeout-এ টের পাওয়া ছড়িয়ে যায় — প্রকৃতিই কিছুটা jitter দেয়। বাকি প্রতিরক্ষা server-এর হাতে: প্রতি gateway-তে নতুন সংযোগের token bucket (পর্ব ৪৯), সস্তায় “পরে আসুন” বলা (পর্ব ১৮-এর load shedding), আর TLS session resumption-এ handshake-এর CPU কমানো। ফিরে আসা client পুরো ইতিহাস চায় না, শুধু cursor-এর পরেরটুকু — না হলে storm পৌঁছে যেত message store পর্যন্ত।

৭ · Deep dive ২ — বার্তার নিশ্চয়তা: id, seq, dedup, sync আর group fan-out

চারটি নিয়মে পুরো নিশ্চয়তা দাঁড়ায়, প্রতিটি আগের কোনো পর্বের প্রয়োগ:

1. Client id → idempotent send: retry নিরাপদ, server-এ duplicate নেই (পর্ব ৩৪)।
2. Server-এর seq → ক্রম: ফোনের ঘড়ি নয়, কথোপকথনের লেখক ক্রম ঠিক করে; ফোনের ঘড়ি ভুল হতে পারে (পর্ব ৩৯)।
3. At-least-once + dedup: ack না পেলে server আবার পাঠায়; গ্রাহক seq দেখে দ্বিতীয় কপি ফেলে, ফাঁক থাকলে পরেরটি আটকে রাখে।
4. প্রতি ডিভাইসের cursor: “কোথা পর্যন্ত পেয়েছি” — reconnect-এর পর সেখান থেকে sync.

নিচের simulator একটি group-এর: A আর B দুজনেই চারটি করে বার্তা পাঠান, ৩০% পাঠানো আর ৩০% ack হারায় (ধরা যাক)। প্রত্যেকের একটিই বার্তা পথে থাকে, তাই নিজের ক্রম ঠিক থাকে। তারপর server থেকে C-র কাছে কপিগুলো দেরিতে, দুবার বা উল্টো ক্রমে যায়:

// Group chat over flaky links. Senders retry with the SAME client id; the server dedups by id
// and assigns seq; receiver C gets copies late, twice or out of order, then dedups and reorders.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const rnd = mulberry32(42), LOSS = 0.3, ACK_LOSS = 0.3;   // ধরা যাক: 30% of sends and acks lost
const outbox = { A: ["A1", "A2", "A3", "A4"], B: ["B1", "B2", "B3", "B4"] };  // client ids
const seqOf = new Map(), log = []; let attempts = 0, dupAtServer = 0;
for (let tick = 0; outbox.A.length + outbox.B.length > 0; tick++) {
  for (const who of ["A", "B"]) {
    const cid = outbox[who][0]; if (!cid) continue;   // one in flight per sender: keeps its order
    attempts++; if (rnd() < LOSS) continue;           // lost on the way: retry next tick
    if (seqOf.has(cid)) dupAtServer++;                // retry of a stored message: same seq back
    else { seqOf.set(cid, log.length + 1); log.push(cid); }
    if (rnd() >= ACK_LOSS) outbox[who].shift();       // ack arrived: next message
  }
}
console.log("sends " + attempts + ", duplicates absorbed by server " + dupAtServer);
console.log("server log: " + log.map((c, i) => (i + 1) + ":" + c).join(" "));
const copies = [];                                     // server -> C: at-least-once, any order
log.forEach((cid, i) => { copies.push([i + rnd() * 3, i + 1]);
  if (rnd() < 0.35) copies.push([i + 2 + rnd() * 3, i + 1]); });   // redelivered after lost ack
copies.sort((x, y) => x[0] - y[0]);
const naive = copies.map(([, s]) => log[s - 1]);
console.log("naive arrival: " + naive.join(" "));
const seen = new Set(), held = new Set(), shown = []; let next = 1, dropped = 0, maxHeld = 0;
for (const [, s] of copies) {
  if (seen.has(s)) { dropped++; continue; } seen.add(s); held.add(s);
  while (held.has(next)) { held.delete(next); shown.push(next + ":" + log[next - 1]); next++; }
  maxHeld = Math.max(maxHeld, held.size);
}
console.log("C shows:       " + shown.join(" "));
console.log("dropped duplicates " + dropped + ", max held waiting for a gap " + maxHeld);

sends 20, duplicates absorbed by server 5
server log: 1:A1 2:B1 3:B2 4:A2 5:A3 6:A4 7:B3 8:B4
naive arrival: B1 A1 A1 A2 B2 B1 A4 B2 B3 A3 A2 A4 B4
C shows:       1:A1 2:B1 3:B2 4:A2 5:A3 6:A4 7:B3 8:B4
dropped duplicates 5, max held waiting for a gap 2

ফাঁক বেশিক্ষণ না ভরলে ডিভাইস নিজেই sync চায় — কপি আসার ভরসায় চিরকাল বসে থাকে না। অফলাইন থেকে ফিরে আসাও একই sync. তানভীরের ফোন তিন ঘণ্টা নেটওয়ার্কের বাইরে ছিল:

একজনের ৫০০টি কথোপকথন থাকলে ৫০০টি “শেষ seq” পড়া ভারী। তাই প্রতিটি ব্যবহারকারীর একটি ছোট “বদলানো কথোপকথন” তালিকা রাখা হয়: নতুন বার্তা এলে প্রতিটি সদস্যের তালিকায় শুধু conv_id যোগ হয়। এটি ছোট মাপের fan-out on write — বার্তার কপি নয়, এক লাইনের ইঙ্গিত। Group-এ এই fan-out কেমন দেখায়, দেখুন:

৮ · Deep dive ৩ — Presence: heartbeat, TTL আর fan-out-এর দাম

Presence নির্ণয় সহজ: heartbeat এলে presence key-এর মেয়াদ নবায়ন, না এলে TTL-এ মুছে যাওয়া; শেষ heartbeat-এর সময়ই last seen (পর্ব ১০, তত্ত্ব পর্ব ৪৪)। কঠিন অংশ অন্যটি — খবরটি কাকে জানাবেন। সবচেয়ে সরল উত্তর: প্রতিটি অনলাইন contact-কে। ট্রেনের দুর্বল নেটওয়ার্কে তানভীর ঘণ্টায় কয়েকবার অনলাইন-অফলাইন হলে প্রতিবার তাঁর শত শত contact-এর কাছে খবর যায়। নিচে ২ লাখ ব্যবহারকারীর একটি নমুনায় তিনটি নীতি তুলনা করা হয়েছে:

// Presence fan-out for a sample of 200,000 users (ধরা যাক). Who must hear "X went online/offline"?
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const rnd = mulberry32(57), U = 200000, ONLINE = 0.3;
const CHANGES_PER_H = 6;   // online/offline flips per online user per hour on a flaky mobile link
const FLAP = 0.5;          // share of flips undone within 10 s (a short network drop)
const VIEW = 8;            // presence dots on one open screen (chat list rows or an open chat)
const contacts = [], online = [];
for (let u = 0; u < U; u++) {   // heavy tail: most have 50-300 contacts, a few have thousands
  contacts.push(Math.min(5000, Math.floor(40 / Math.pow(1 - rnd(), 0.8))));
  online.push(rnd() < ONLINE);
}
const pool = [];                // a user appears in others' lists in proportion to contacts
contacts.forEach((c, u) => { for (let k = 0; k < c; k += 40) pool.push(u); });
const subs = new Array(U).fill(0);
for (let u = 0; u < U; u++) if (online[u])            // each online viewer watches VIEW users
  for (let k = 0; k < VIEW; k++) subs[pool[Math.floor(rnd() * pool.length)]]++;
let naive = 0, onView = 0, busiest = 0, n = 0;
for (let u = 0; u < U; u++) if (online[u]) { n++;
  naive += CHANGES_PER_H * contacts[u] * ONLINE;     // tell every online contact
  onView += CHANGES_PER_H * subs[u];                 // tell only those looking right now
  busiest = Math.max(busiest, subs[u]); }
const avgC = contacts.reduce((a, b) => a + b, 0) / U, f = (x) => Math.round(x / 3600).toLocaleString("en-US");
console.log("online users " + n.toLocaleString("en-US") + ", avg contacts " + avgC.toFixed(0) + ", max " + contacts.reduce((a, b) => Math.max(a, b)));
console.log("naive broadcast to online contacts  " + f(naive).padStart(9) + " events/s");
console.log("subscribe-on-view                   " + f(onView).padStart(9) + " events/s");
console.log("subscribe-on-view + 10 s debounce   " + f(onView * (1 - FLAP)).padStart(9) + " events/s");
console.log("most-watched user has " + busiest + " live viewers");

online users 59,930, avg contacts 152, max 5000
naive broadcast to online contacts      4,594 events/s
subscribe-on-view                         240 events/s
subscribe-on-view + 10 s debounce         120 events/s
most-watched user has 92 live viewers

তিনটি কৌশল এখান থেকেই আসে:

• Lazy presence: chat তালিকা বা একটি chat খুললে ফোন শুধু দৃশ্যমান মানুষদের presence-এ subscribe করে, পর্দা বদলালে ছেড়ে দেয়। খোলার মুহূর্তে একবার পড়ে নেওয়া (pull), তারপর বদল এলে push.
• Debounce আর coalescing: অনলাইন থেকে অফলাইন জানানোর আগে কয়েক সেকেন্ড অপেক্ষা; এর মধ্যে ফিরে এলে কিছুই পাঠানো হয় না। অনলাইন-অফলাইনের এই দোল (flapping-এর মতো) এভাবেই থামে। একই সময়ে কয়েকটি বদল একটি batch-এ।
• Group-এ মোটা দাগে: ৫০০ সদস্যের group-এ প্রত্যেকের সবুজ বিন্দু নয়, বড়জোর “১২ জন অনলাইন” — বা কিছুই নয়। Typing indicator আরও ক্ষণস্থায়ী: জমা হয় না, হারালেও ক্ষতি নেই, তাই at-most-once যথেষ্ট (পর্ব ৩৪)। বার্তা, receipt আর presence — তিন রকম খবরের তিন রকম নিশ্চয়তা।

গোপনীয়তার সেটিংও এখানে ঢোকে: কেউ last seen লুকালে তাঁর খবর কাউকে পাঠানো হয় না, যা খরচও কমায়। Presence store বসে গেলে সবাই কিছুক্ষণ “অফলাইন” দেখাবে, কিন্তু বার্তা চলবে — এটিই graceful degradation.

৯ · ভাঙন, trade-off আর বিস্তার — encryption, region, spam আর wrap-up

কী মরলে কী হয়

End-to-end encryption — ধারণার স্তরে

End-to-end encryption (E2EE)-এ বার্তা প্রেরকের ডিভাইসে encrypt হয়, খোলা যায় শুধু প্রাপকের ডিভাইসে; server বহন করে অস্বচ্ছ bytes. বহুল ব্যবহৃত নকশা Signal protocol, যার specification Signal-এর পক্ষ থেকে প্রকাশিত (মূল অংশগুলো ২০১৬ সালের দিকে): চাবি বিনিময়ের একটি handshake, তারপর প্রতিটি বার্তায় চাবি বদলে চলা “double ratchet”, যা forward secrecy দেয়। খুঁটিনাটি আর সংস্করণ সময়ের সাথে বদলেছে; নিরাপত্তার বিচার বিশেষজ্ঞ পর্যালোচনার বিষয়, এখানে আমরা দেখি নকশায় প্রভাব (পর্ব ৫২, Computer Networks · cryptography).

• Server-এ search নেই: বিষয়বস্তু server পড়তে পারে না, তাই পর্ব ২৭-এর inverted index ফোনেই বানাতে হয়।
• Moderation বদলায়: বিষয়বস্তু স্ক্যান অসম্ভব; ভরসা ব্যবহারকারীর report (তখন ডিভাইস নিজেই বার্তাগুলো পাঠায়), আর metadata-র সংকেত — হার, নতুন অ্যাকাউন্ট, অচেনা মানুষকে গণবার্তা।
• প্রতিটি ডিভাইসের নিজের চাবি: নতুন ডিভাইসে পুরোনো ইতিহাস আনতে আলাদা encrypted backup বা ডিভাইস-থেকে-ডিভাইস স্থানান্তর লাগে। Group-এ প্রতিটি প্রেরকের একটি sender key সব সদস্যকে আগে দেওয়া থাকলে বার্তা একবার encrypt করলেই চলে।
• Media: ফোন ছবিটি encrypt করে upload করে; চাবিটি যায় encrypted বার্তার ভেতরে। Object storage রাখে শুধু ciphertext.
• Metadata থেকেই যায়: কে কাকে, কখন, কত বড় বার্তা — server দেখে। এটিকে কমানো আলাদা গবেষণার বিষয়।

Multi-region, ১০ গুণ বৃদ্ধি, spam আর observability

Multi-region: প্রতিটি কথোপকথনের একটি home region, যেখানে তার একক লেখক থাকে। দূরের প্রবাসী সদস্য কাছের gateway-তে যুক্ত হন, বার্তা home region-এ গিয়ে seq পায় — বাড়তি latency মোটামুটি একটি দূরপাল্লার round trip. দুই region-এ একসাথে লেখক রাখলে conflict-এর জটিলতা আসে (পর্ব ২২, পর্ব ৪৬); chat-এ একক লেখকই সাধারণত সরল আর নিরাপদ।

১০ গুণে কী ভাঙবে: ডিভাইস-কপি সেকেন্ডে কোটির ঘরে, receipt তার চেয়েও বেশি, registry lookup, আর storage. প্রতিকার: gateway ধরে batch, receipt-কে watermark বানানো, registry-কে shard করা, পুরোনো bucket সস্তা storage-এ নামানো।

Spam আর অপব্যবহার (প্রতিরক্ষামূলক): নম্বর যাচাইয়ে OTP — SMS-এর নির্ভরযোগ্যতা পর্ব ৫৭-এ; অ্যাকাউন্ট আর ডিভাইস ধরে পাঠানো, নতুন অচেনা কথোপকথন আর group-এ যোগ করার rate limit (পর্ব ৪৯); forward-এর সংখ্যা সীমিত করা আর “অনেকবার forward করা” চিহ্ন; block আর report. E2EE-তে এই সংকেতগুলোই প্রধান ভরসা।

কী মাপবেন আর কিসে alert: send থেকে ack-এর p99, অনলাইন-থেকে-অনলাইন delivery-র p99, ack-ব্যর্থতার হার, reconnect-এর হার, প্রতি gateway-তে সংযোগ, sync-এর পিছিয়ে থাকা, push-ব্যর্থতা (পর্ব ৫০)। হঠাৎ reconnect বেড়ে যাওয়া আর delivery latency-র SLO burn — এই দুটি alert সবার আগে। খরচ: সবচেয়ে বড় খাত media storage আর CDN-এর egress, তারপর gateway; text তুলনায় সস্তা।

১০ · AI-এর যুগে — AI-এর দেওয়া chat নকশা যাচাই

“একটি জনপ্রিয় messaging অ্যাপের মতো chat system design করো” — AI কয়েক সেকেন্ডে সুন্দর ছবি দেয়, প্রায়ই Kafka, Redis আর microservices দিয়ে ভরা। কিন্তু chat-এর আসল কঠিন অংশগুলো — ক্রম, duplicate, অফলাইন ডিভাইস আর reconnect — সেখানে প্রায়ই এক লাইনে সারা হয়। চেনা ভুলগুলো:

AI-এর নকশা মানার আগে — চেকলিস্ট

• সব সংখ্যা নিজে আবার হিসাব করেছি — বিশেষত ডিভাইস-কপি, receipt আর সংযোগ
• প্রতিটি বার্তায় client id আছে, আর ack আসে শুধু টেকসই লেখার পরে
• ক্রম আসে server-এর per-conversation seq থেকে; একক লেখকের failover-এ fencing আছে
• অফলাইন, multi-device আর cursor থেকে sync-এর পথ আঁকা আছে
• Gateway মরার ঘটনা simulation-এ চালিয়েছি; প্রথম চেষ্টাও ছড়ানো
• Presence আর typing-এর জন্য সস্তা নীতি; E2EE-র দাবি আর search বা moderation-এর দাবি পরস্পরবিরোধী নয়
• পণ্যের সীমা অফিশিয়াল ডকুমেন্টেশনে মিলিয়েছি, আর অপ্রয়োজনীয় অংশ বাদ দিয়েছি