WhatsApp-এর মতো chat অ্যাপ ডিজাইন

লক্ষ্য: user এক-থেকে-এক ও group-এ real-time টেক্সট message পাঠায়, সাথে delivery status।

Requirement

এক-থেকে-এক ও group chat, sent/delivered/read status সহ।
Message হারাবে না, আর chat-এর ভেতরে ক্রম থাকবে।
Offline user ফিরলে message পাবে।
কম latency (এক সেকেন্ডের অনেক কম) এবং অনেক একসাথে connection।

অনুমান

ধরুন ৫ কোটি দৈনিক user, প্রত্যেকে দিনে ৪০টি message: দিনে ২০০ কোটি message, গড়ে প্রায় ২৩,০০০ message/s। প্রতিটি ১০০ byte হলে দিনে প্রায় ২০০ GB টেক্সট। Media (ছবি, voice) যায় object storage-এ, message-এ শুধু রেফারেন্স।

Connection

প্রতিটি online user একটি chat server-এ WebSocket ধরে রাখে। একটি server কয়েক লাখ connection ধরতে পারে। একটি session service (Redis) user -> chat server ম্যাপ রাখে, তাই কোথায় পৌঁছাতে হবে জানা যায়।

Message পাঠানো (এক-থেকে-এক)

প্রেরকের অ্যাপ WebSocket দিয়ে নিজের chat server-এ message পাঠায়, সাথে client-এর বানানো message ID।
Server message টেকসইভাবে সংরক্ষণ করে (প্রেরককে ack দেয়: "sent")।
প্রাপকের chat server খুঁজে এগিয়ে দেয়। প্রাপক online হলে socket দিয়ে push হয় ও সে "delivered" ack পাঠায়।
প্রাপক offline হলে message storage-এ থাকে এবং push notification যায়। ফিরে এলে অ্যাপ শেষ message ID-র পরের সব sync করে।

ক্রম ও ডুপ্লিকেট

প্রতি কথোপকথনে server-এর দেওয়া sequence number বা সময়-ক্রমিক ID দিয়ে সাজান। Ack হারাতে পারে ও client retry করে, তাই message ID পাঠানোকে idempotent করে এবং ডুপ্লিকেট ঠেকায়।

Storage

Write-ভারী এবং কথোপকথন ও সময় অনুযায়ী ক্রমিক। conversation_id দিয়ে partition করা wide-column বা key-value store মানায় (Cassandra, DynamoDB ধাঁচ)। সাম্প্রতিক message গরম রাখুন, পুরোনো archive করুন।

Group chat

পাঠানোর সময় server প্রতিটি সদস্যের inbox-এ message ছড়িয়ে দেয়। ছোট group-এ write-সময়ের fan-out ঠিক। খুব বড় group-এ একবার রেখে সদস্যরা নিয়ে নেয়।

অন্যান্য বিষয়

Presence (online/শেষ দেখা): heartbeat, Redis-এ ছোট মেয়াদে রাখা।
End-to-end encryption: server এমন ciphertext রাখে ও পাঠায় যা সে পড়তে পারে না; key থাকে device-এ।
Media: presigned URL দিয়ে object storage-এ upload, লিংক পাঠান।

মূল কথা: WebSocket gateway, session map, আগে টেকসই সংরক্ষণ তারপর delivery, idempotency-র জন্য client message ID, এবং কথোপকথন-ভিত্তিক ক্রম।

System Design সিরিজ, পর্ব ৩ (case study): 3 নম্বর (মোট 16)। আগের লেখা: Pastebin ডিজাইন: টেক্সট রাখা ও শেয়ার করা.