Chat System: পূর্ণ মক ইন্টারভিউ

এই পাঠে যা শিখবেন

• Chat-এর পূর্ণ interview response অনুসরণ
• Durability, ordering ও reconnect নিয়ে deep dive
• Multi-device receipt ও privacy limit প্রকাশ

সমস্যা দিয়ে শুরু

Interviewer: WhatsApp-এর মতো chat design করুন। Candidate: প্রথম scope one-to-one এবং সর্বোচ্চ ১০০ member group; message text, history, realtime delivery এবং offline sync রাখছি। Voice/video, global search ও end-to-end encryption এখন বাইরে, কারণ key management protocol আলাদা deep dive চাইবে। Interviewer সম্মতি দিলেন। Candidate acceptance semantics স্পষ্ট করলেন: API success মানে durable message stored; delivery এবং read receiver-generated পরে আসবে। এই scope না বললে encryption ও privacy promise ভুলভাবে বোঝানো হতে পারে।

সহজ করে বুঝি

Candidate response: POST /conversations/{id}/messages client_message_id নেবে, membership ও body limit validate করবে। GET /conversations/{id}/messages?after=sequence reconnect gap দেবে। messages table conversation_id,sequence,sender_id,client_message_id,body,created_at; unique conversation sequence এবং sender-scoped operation identity। Membership change current permission দিয়ে history access নিয়ন্ত্রণ করবে। Read cursor প্রতিটি user/device policy অনুযায়ী রাখা যায়। Message body edit/delete versioned update হিসেবে propagate হবে।

পরিচিত একটি উপমা

Post office চিঠি গ্রহণের seal দিলে durable acceptance, বাড়ির স্বাক্ষর delivery এবং recipient পড়া read receipt-এর মতো। Courier network live notification পৌঁছায়; central register history রাখে। Network না থাকলে register থেকে পরে missing চিঠি সংগ্রহ করা যায়।

নকশাটি দেখুন

flowchart TD
 S[Sender device] --> A[Membership checked send API]
 A --> D[(Ordered message storage)]
 A --> O[Outbox delivery event]
 O --> P[Cross gateway Pub Sub]
 P --> G[Recipient socket gateway]
 G --> R[Recipient device]
 R --> K[Device ack and read cursor]
 X[Reconnect after sequence] --> D

Candidate: message ও outbox local transaction-এ লিখব, response stable message ID দেবে। Relay gateway backbone-এ event পাঠাবে। Recipient socket পেলে sequence dedupe করে render করবে। Disconnect হলে last cursor নিয়ে history sync। Interviewer: publish হারালে? Candidate: outbox relay retry, তারপরও client reconnect history দিয়ে gap পূরণ করবে। Duplicate broadcast client message ID/sequence দিয়ে ignore করবে। Pub/Sub durability promise-এর একমাত্র স্তর নয়।

PHP ও Laravel-এ প্রয়োগ

Estimate assumption: ১০ লাখ active user, প্রতিদিন গড়ে ২০ message হলে ২ কোটি daily writes, average প্রায় ২৩১/second। Group fan-out, delivery receipts এবং connection concurrency আলাদা হিসাব; DAU থেকে concurrent socket সরাসরি বের হয় না। ৫০০ byte text+metadata ধরলে দিনে প্রায় ১০GB raw, indexes/media/replicas অতিরিক্ত। Laravel fragment reconnect query; conversation membership আগে authorized এবং sequence indexed। Request cursor integer validated; response maximum ১০০ record।

use App\Models\Message;
$messages = Message::query()
    ->where('conversation_id', $conversation->id)
    ->where('sequence', '>', $request->integer('after'))
    ->orderBy('sequence')
    ->limit(100)->get();
return response()->json([
    'messages' => $messages,
    'next_cursor' => $messages->last()?->sequence,
]);

সুবিধা, সীমাবদ্ধতা ও trade-off

Interviewer: ordering কীভাবে? Candidate: প্রতি conversation authoritative sequence allocator বা partition owner রাখব। Simple DB row lock small group-এ শুরু হতে পারে; hot group-এ throughput bottleneck হবে। Global order চাইছি না। WebSocket persistent connection timely push দেয়, কিন্তু load balancer connection budget, sticky routing strategy এবং gateway drain দরকার। Presence heartbeat lease approximate; unexpected disconnect তাৎক্ষণিক offline হবে না।

সাধারণ ভুল

• API accepted, delivered ও read এক state বানানো।
• Group membership authorization শুধু frontend-এ রাখা।
• Reconnect history ছাড়া socket delivery-কে durable chat বলা।

আরও একটু গভীরে

Candidate deep dive: send request commit হলো কিন্তু response হারাল। Retry একই client_message_id ব্যবহার করবে; unique constraint dedupe করে existing message ফেরাবে। Payload আলাদা হলে conflict policy, নিঃশব্দ overwrite নয়। Device offline backlog বড় হলে paged sync এবং retention boundary দিতে হবে। Slow device gateway buffer bounded; overflow হলে disconnect করে durable catch-up route দেখাব। Multi-device read cursor highest read sequence aggregate করা যাবে কি না product policy; privacy setting এবং receipt disabling respect করতে হবে। Observability-তে acceptance latency, delivery lag, reconnect gap, duplicate rate ও gateway connection count থাকবে। Regional outage-এ history durability ও ordering owner failover protocol দরকার; এই starter mock globally ordered active-active claim করে না। Attachments আলাদা authorized upload/storage pipeline।

মনে রাখুন

পূর্ণ chat mock durable acceptance, conversation order, live fan-out এবং reconnect history-কে পৃথক কিন্তু যুক্ত contract হিসেবে প্রকাশ করে।

নিজে চেষ্টা করুন

Mock-এ interviewer হয়ে তিন followup দিন: ১০ লাখ member group, end-to-end encryption, region failover। Candidate হিসেবে কোন assumption আর valid নয় লিখুন। Duplicate send এবং missing broadcast-এর sequence diagram আঁকুন। Protocol version migration old client-এ কীভাবে চলবে ব্যাখ্যা করুন।

নিজের বোঝা যাচাই করুন

1. Accepted মানে কী?

এই scope-এ message durable storage-এ আছে। Recipient device বা user পড়েছেন এমন promise নয়।

2. Connection হারালে?

Stable cursor নিয়ে history query করে gap পূরণ করে। Live Pub/Sub duplicate বা loss durable store-এ নির্ভরশীল sync দিয়ে সামলায়।

3. Ordering unit কেন conversation?

User requirement সেই boundary-তে; global total order অযথা coordination বাড়ায়। Hot group-এর strategy আলাদা লাগতে পারে।

4. Retry নতুন ID দিলে?

নতুন logical message হিসেবে তৈরি হতে পারে। Same send operation stable client identity নিয়ে retry করবে।

5. E2EE কেন বাইরে?

Key distribution, membership change এবং recovery semantics বড় protocol change। এটি বাদ দেওয়ার সীমা explicit; ordinary TLS-কে E2EE বলা যাবে না।

আরও পড়ুন

• Laravel private broadcasting channels
• WebSocket protocol
• Laravel transactions