৫০,০০০ student একসাথে class দেখছে। কে কোন class এ আছে? কতজন live দেখছে? Teacher chat করলে সবাই
পাচ্ছে?
HTTP polling দিয়ে এটা করলে server মরে যাবে। WebSocket + Socket.IO + Redis দিয়ে কীভাবে এটা handle করা
হয়েছে — সেটাই আজকের বিষয়।
Realtime feature এ HTTP polling vs WebSocket এর তুলনা।
Client connect হলে কী হয় — initialization থেকে event handling পর্যন্ত।
ENABLE_RECORDED_CLASS_WATCH=false
হলে chat + progress module disable। Core presence সবসময় on।Anonymous কেউ socket connect করতে পারে না। প্রতিটা connection JWT verify করে।
cache:socket:user:v2:{role}:{id}
→ Redis 2min TTL → Prisma fallback।socket.user = { id, role, name, avatar }
set হয়। সব event handler এ এটা থেকে user জানা যায় — আর JWT verify করতে হয় না।এক class এ হাজার হাজার viewer। তাদের count করতে হবে exact বা approximate — Redis ZSET + HLL দিয়ে।
প্রতি 1s এ সব room broadcast করলে chaos হবে। Smart conditions দিয়ে শুধু দরকারে emit।
markRoomDirty()
call হলেই room process হয়। কেউ join/leave না করলে — broadcast নেই।Class চলাকালীন student chat করে। Rate limit না থাকলে spam, delay থাকলে laggy — এই balance কীভাবে করা হয়েছে।
chat_dropped_overflow
metric। Data drop হয় — spam protect।একটা server এ ৫০K connection সম্ভব না। Multiple server দরকার — Redis Adapter দিয়ে সব server sync।
Server বন্ধ হলে data হারাবে না। আর সব কিছু monitor করতে metrics।
প্রতিটা design decision এর কারণ আছে — performance, security, resilience।
io.on('connection') না —
মানে auth layer, presence buffering, smart broadcasting, rate limiting, graceful shutdown — সব
একসাথে। এই architecture দিয়ে লাখ user handle করা সম্ভব।