ধরো, তুমি একটি রিয়েল-টাইম চ্যাট অ্যাপ্লিকেশন (Real-time Chat App) বানাচ্ছো। একজন ইউজার মেসেজ টাইপ করে সেন্ড বাটনে চাপ দেওয়ার সাথে সাথেই অন্য ইউজারের স্ক্রিনে সেটি ভেসে উঠবে—মাঝখানে কোনো লেটেন্সি বা ডিলে (Delay) থাকবে না। অথবা তুমি একটি লাইভ স্টক ট্রেডিং (Stock Trading) সিস্টেম ডিজাইন করছ, যেখানে প্রতি সেকেন্ডে শেয়ারের দাম ওঠানামা করছে এবং তা ইউজারদের ড্যাশবোর্ডে সাথে সাথে আপডেট হচ্ছে।
এই ধরনের কাজগুলোর জন্য ট্র্যাডিশনাল HTTP প্রটোকল যথেষ্ট নয়। ঠিক এই জায়গাতেই সিস্টেম ডিজাইনের সুপারহিরো হিসেবে আবির্ভূত হয় WebSockets।
WebSockets কী?
WebSocket হলো একটি Full-Duplex (দ্বিমুখী) কমিউনিকেশন প্রটোকল। এটি ক্লায়েন্ট (যেমন: ওয়েব ব্রাউজার) এবং সার্ভারের মধ্যে একটি Persistent Connection বা দীর্ঘস্থায়ী সংযোগ তৈরি করে রাখে।
এর মানে হলো, একবার কানেকশন তৈরি হয়ে গেলে ক্লায়েন্ট বা সার্ভার—যে কেউ যখন খুশি একে অপরকে ডেটা পাঠাতে পারে। ডেটা পাঠানোর জন্য প্রতিবার নতুন করে কানেকশন তৈরি করার প্রয়োজন হয় না (যেটি HTTP-তে করতে হয়)।
HTTP বনাম WebSockets: কোর পার্থক্য
HTTP হলো একটি 'Pull-based' প্রটোকল, যেখানে ক্লায়েন্টকে বারবার সার্ভারকে জিজ্ঞেস করতে হয়, "নতুন কোনো ডেটা আছে কি?" (যাকে Long Polling বলা হয়)। অন্যদিকে WebSocket হলো 'Push-based'—সার্ভারের কাছে নতুন ডেটা আসামাত্রই সে নিজে থেকে ক্লায়েন্টকে পুশ করে দেয়।
বৈশিষ্ট্য | HTTP (Traditional) | WebSockets |
Communication | Half-Duplex (একদিকে ডেটা যায়)। | Full-Duplex (একই সাথে দুই দিকে ডেটা যায়)। |
Connection Lifecycle | Request-Response ভিত্তিক (কাজ শেষ হলে কানেকশন ক্লোজ)। | Persistent Connection (কানেকশন ওপেন থাকে)। |
Overhead | প্রতিটি রিকোয়েস্টে বিশাল হেডার (Header) থাকে। | একবার কানেক্ট হওয়ার পর ডেটা ফ্রেম অনেক হালকা হয়। |
Latency | বেশি (প্রতিবার হ্যান্ডশেক করতে হয়)। | অত্যন্ত কম (Lightning fast)। |
Use Cases | স্ট্যাটিক ওয়েবসাইট, সাধারণ REST API। | লাইভ চ্যাট, মাল্টিপ্লেয়ার গেম, রিয়েল-টাইম ড্যাশবোর্ড। |
The Handshake: কানেকশন কীভাবে তৈরি হয়? (Deep Dive)
WebSocket কানেকশন কিন্তু শুরু থেকেই WebSocket থাকে না! এটি মূলত একটি সাধারণ HTTP রিকোয়েস্ট দিয়েই শুরু হয়। ক্লায়েন্ট সার্ভারকে একটি HTTP GET রিকোয়েস্ট পাঠায়, যেখানে একটি বিশেষ হেডার থাকে: Upgrade: websocket এবং Connection: Upgrade।
সার্ভার যদি WebSocket সাপোর্ট করে, তবে সে 101 Switching Protocols স্ট্যাটাস কোড দিয়ে রেসপন্স করে। এই রেসপন্সের পরই HTTP কানেকশনটি আপগ্রেড হয়ে WebSocket প্রটোকলে (ws:// বা wss://) রূপান্তরিত হয় এবং এটি আর কখনো ক্লোজ হয় না, যতক্ষণ না ক্লায়েন্ট বা সার্ভার ইচ্ছে করে তা বন্ধ করে।
System Design Architecture for WebSockets
একটি রিয়েল-টাইম সিস্টেম ডিজাইন করা সাধারণ REST API বানানোর চেয়ে অনেক বেশি চ্যালেঞ্জিং। এখানে যে বিষয়গুলো মাথায় রাখতে হয়:
১. Connection Handling এবং The C10K Problem
যেহেতু কানেকশনগুলো Persistent (দীর্ঘস্থায়ী), তাই সার্ভারকে প্রতিটি ক্লায়েন্টের জন্য একটি করে সকেট (Socket) বা ফাইল ডেসক্রিপ্টর ওপেন রাখতে হয়। ধরো, তোমার সিস্টেমে ১ লক্ষ ইউজার অনলাইনে আছে। এর মানে হলো সার্ভারকে ১ লক্ষ ওপেন কানেকশন মেইনটেইন করতে হবে!
সমাধান: Apache-এর মতো থ্রেড-বেসড সার্ভার এখানে কাজ করবে না। তোমাকে Node.js, Go, Elixir, বা Python-এর (FastAPI) মতো Event-driven / Async সার্ভার ব্যবহার করতে হবে।
২. Scalability এবং Load Balancing
একটি মাত্র সার্ভার কখনোই লক্ষ লক্ষ কানেকশন হ্যান্ডেল করতে পারবে না। তোমাকে লোড ব্যালেন্সার (যেমন: NGINX, HAProxy, AWS API Gateway) ব্যবহার করতে হবে।
তবে সমস্যা হলো, WebSocket স্টেটফুল (Stateful)। তাই লোড ব্যালেন্সারে "Sticky Sessions" এনাবল করতে হয়, যেন একজন ইউজারের সব ডেটা নির্দিষ্ট সেই সার্ভারেই যায় যার সাথে তার কানেকশন ওপেন আছে।
৩. Message Routing (Pub/Sub)
ধরো, ইউজার 'A' কানেক্টেড আছে সার্ভার-১ এর সাথে এবং ইউজার 'B' কানেক্টেড আছে সার্ভার-২ এর সাথে। ইউজার 'A' যদি 'B'-কে মেসেজ পাঠায়, তবে সার্ভার-১ কীভাবে তা সার্ভার-২ কে জানাবে?
সমাধান: এখানে Message Broker (যেমন: Redis Pub/Sub বা Kafka) ব্যবহার করতে হয়। প্রতিটি সার্ভার Redis-এ সাবস্ক্রাইব করে রাখে। সার্ভার-১ মেসেজটি Redis-এ পাবলিশ করে, এবং Redis সেটি ব্রডকাস্ট করে সার্ভার-২ এর কাছে পৌঁছে দেয়।
৪. Fault Tolerance এবং Heartbeats
কানেকশন ড্রপ হলে কী হবে? ক্লায়েন্টের সাইডে অটো-রিকানেক্ট (Auto-reconnect) লজিক থাকতে হবে।
অন্যদিকে, ক্লায়েন্টের ইন্টারনেট চলে গেলে সার্ভার অনেক সময় বুঝতে পারে না যে সকেটটি ডেড (Dead)। এই "Ghost Connections" ক্লিন করার জন্য Ping/Pong (Heartbeats) মেকানিজম ব্যবহার করা হয়। সার্ভার প্রতি ২০-৩০ সেকেন্ড পর পর ক্লায়েন্টকে একটি Ping ফ্রেম পাঠায়, ক্লায়েন্ট Pong ফ্রেম দিয়ে রেসপন্স না করলে সার্ভার কানেকশনটি কিল (Kill) করে দেয়।
৫. Security
HTTP-এর মতো WebSockets-এও সিকিউরিটির লেয়ার থাকা বাধ্যতামূলক।
WSS (WebSocket Secure): সবসময়
ws://এর বদলেwss://ব্যবহার করতে হবে, যা TLS এনক্রিপশন সাপোর্ট করে।Authentication: হ্যান্ডশেক হওয়ার সময়ই টোকেন (JWT) বা কুকি ভেরিফাই করে নিতে হবে।
Rate Limiting: কোনো ইউজার যেন প্রতি সেকেন্ডে হাজার হাজার মেসেজ পাঠিয়ে সার্ভার ডাউন (DDoS) করে দিতে না পারে, সেদিকে খেয়াল রাখতে হবে।
Example: Real-time Chat with FastAPI
নিচে পাইথনের আধুনিক ফ্রেমওয়ার্ক FastAPI ব্যবহার করে একটি রিয়েল-টাইম চ্যাট রুমের বেসিক আর্কিটেকচার দেখানো হলো, যেখানে ব্রডকাস্টিং মেকানিজম ইমপ্লিমেন্ট করা হয়েছে।
from fastapi import FastAPI, WebSocket, WebSocketDisconnect
from typing import List
app = FastAPI()
# Connection Manager handles all active websocket connections
class ConnectionManager:
def __init__(self):
# Storing active connections in memory
self.active_connections: List[WebSocket] = []
async def connect(self, websocket: WebSocket):
# Accept the incoming connection handshake
await websocket.accept()
self.active_connections.append(websocket)
def disconnect(self, websocket: WebSocket):
# Remove connection when client drops
self.active_connections.remove(websocket)
async def broadcast(self, message: str):
# Push the message to all connected clients
for connection in self.active_connections:
await connection.send_text(message)
manager = ConnectionManager()
# The WebSocket Endpoint
@app.websocket("/ws/chatroom")
async def chat_endpoint(websocket: WebSocket):
# Establish connection
await manager.connect(websocket)
try:
while True:
# Wait for any incoming message from this specific client
data = await websocket.receive_text()
# Broadcast the received message to everyone in the room
await manager.broadcast(f"User says: {data}")
except WebSocketDisconnect:
# Handle client disconnection gracefully
manager.disconnect(websocket)
await manager.broadcast("A user has left the chatroom.")Real-World Use Cases (কোথায় ব্যবহার করবে?)
১. WhatsApp Web / Messenger: প্রতি মেসেজ ইন্সট্যান্টলি ডেলিভারি করার জন্য।
২. Stock Trading Platform: শেয়ার বাজার বা ক্রিপ্টো এক্সচেঞ্জে (যেমন: Binance) রিয়েল-টাইম প্রাইস আপডেট দেখানোর জন্য।
৩. Online Multiplayer Gaming: ইউজারের মুভমেন্ট এবং গেম স্টেট স্মুথলি সিঙ্ক করার জন্য।
৪. Collaborative Tools: Google Docs বা Figma-এর মতো টুলে, যেখানে একাধিক মানুষ একই সাথে লাইভ এডিট করে।
সিস্টেম ডিজাইনে WebSockets তখনই ব্যবহার করবে যখন তোমার অ্যাপ্লিকেশনে Low-latency এবং Push-based data flow আবশ্যক হবে। এটি সঠিকভাবে ইমপ্লিমেন্ট করতে পারলে তোমার অ্যাপ্লিকেশন হবে লাইটনিং ফাস্ট (Lightning fast), কিন্তু ভুল আর্কিটেকচারে এটি সার্ভারের মেমোরি লিক (Memory leak) করে পুরো সিস্টেম ক্র্যাশ করিয়ে দিতে পারে।