WebSocket বনাম Server-Sent Events বনাম long polling

HTTP হলো request-response: client চায়, server উত্তর দেয়। লাইভ feature-এ server-কে নিজে থেকে পাঠাতে হয়। তিনটি প্রধান উপায় আছে।

Short ও long polling

• Polling: client কয়েক সেকেন্ড পরপর জিজ্ঞেস করে। সহজ, কিন্তু অপচয় ও দেরি হয়।
• Long polling: client জিজ্ঞেস করে, server খবর না পাওয়া পর্যন্ত request ধরে রাখে, উত্তর দিলে client আবার জিজ্ঞেস করে। সব জায়গায় চলে, কিন্তু প্রতি message-এ নতুন request।

Server-Sent Events (SSE)

একটি সাধারণ HTTP response যা খোলা থাকে, content type text/event-stream। Server যখন খুশি event পাঠায়। Browser-এর EventSource এটি সামলায় এবং নিজে থেকে reconnect করে।

• দিক: শুধু server থেকে client।
• ভালো: notification, লাইভ feed, dashboard, progress bar।
• শুধু টেক্সট, এবং সাধারণ HTTP-তে চলে, তাই proxy ও HTTP/2-র সাথে বন্ধুত্বপূর্ণ।

WebSocket

HTTP upgrade handshake-এর পর সংযোগ full-duplex চ্যানেল হয়: দুই পক্ষই যেকোনো সময় খুব কম overhead-এ পাঠাতে পারে।

• ভালো: chat, multiplayer game, একসাথে edit, trading screen।
• Reconnect, heartbeat (ping/pong) ও authentication নিজেকে সামলাতে হয়।

তুলনা

	Long polling	SSE	WebSocket
দিক	দুই (বারবার request দিয়ে)	server থেকে client	দুই
Overhead	বেশি	কম	সবচেয়ে কম
Auto-reconnect	হাতে	বিল্ট-ইন	হাতে
Binary data	হ্যাঁ	না (টেক্সট)	হ্যাঁ
সহজতা	সহজ	সহজ	বেশি কাজ

Real-time connection scale করা

প্রতিটি connection একটি দীর্ঘস্থায়ী socket, তাই server একসাথে অনেক ধরে রাখে। মূল কথা:

• দীর্ঘ connection সমর্থন করে ও যুক্তিসঙ্গত timeout দেয় এমন load balancer নিন।
• User server A-তে যুক্ত, কিন্তু event ঘটছে server B-তে। Pub/sub backplane (Redis, Kafka, NATS) ব্যবহার করুন যাতে প্রতিটি server নিজের client-দের কাছে পৌঁছে দিতে পারে।
• মৃত connection ধরতে heartbeat পাঠান।
• Connect-এর সময় authenticate করুন, token-এর মেয়াদ শেষে আবার যাচাই করুন।

মূল কথা: শুধু নিচে আপডেট ঠেললে SSE নিন। দ্বিমুখী, কম latency-র message লাগলে WebSocket। Long polling শুধু বাধ্য হলে।

---

System Design সিরিজ, পর্ব ২ (building block): 6 নম্বর (মোট 14)। আগের লেখা: Object storage (S3-ধাঁচ): বড় পরিসরে ফাইল রাখা.