৫,০০০ student একটা class এ বসে chat করছে। প্রতি সেকেন্ডে ২০০+ message।
নাইভ approach: সরাসরি DB তে save → DB overwhelmed, UI laggy।
কীভাবে করা হয়েছে? Socket → Token Bucket → Batcher → Redis Stream →
Worker → DB — প্রতিটা layer এর কারণ কী?
বেশিরভাগ developer প্রথমে এটা করে — এবং production এ এসে পস্তায়।
Student "enter" চাপা থেকে DB তে save হওয়া পর্যন্ত — প্রতিটা step কী করে।
Invalid data, spam, banned user — কেউ DB পর্যন্ত পৌঁছাতে পারে না।
Redis call ছাড়াই, socket এর নিজের memory তে — ultra fast rate limiter।
watch:chat:throttled
event emit + বাংলায় message। Counter track হয় metrics এ।Admin যখন student কে ban করে — পরবর্তী message এ instantly blocked। কিন্তু DB call কম রেখে।
FULL — সব কিছু
থেকে banMEDIA_COMMENT
— শুধু chat/comment banbannedUntil: null
— permanent banbannedUntil: Date
— temporary, countdown দেখায়
socket.user.role !== 'student'
হলে check skip — teacher/admin কে restrict করা হয় না।প্রতিটা message আলাদা emit করলে network overhead বিশাল। Batcher দিয়ে ৯৫%+ calls কমানো হয়েছে।
watch:chat:message
(single object)watch:chat:batch
(array)Message accept হওয়ার পরে DB write async। Redis Stream দিয়ে guaranteed, ordered, at-least-once delivery।
enqueueChat().catch(err => console.error)
— fire and forget। Queue fail হলে socket user affected হয় না।আলাদা Node.js process — stream থেকে batch read → Prisma batch write। Fail হলে dead letter, না হারায়।
stream:watch-chat:dead
— max 10K. reason + original data। Debug করা যায়।Messages DB তে কীভাবে store হয়? আর পুরনো data কীভাবে automatically delete হয়?
Teacher class এ কী বলছে, student কী লিখছে — SuperAdmin একটা dashboard থেকে সব monitor করে।
emitAdminChat()
instant। Admin real-time monitoring নির্ভুল।প্রতিটা layer এর design decision — কেন করা হয়েছে।