Chapter 12 · Hinglish · Sunne-wala Sabak
Chat System — Sockets, Presence aur Offline Reach
WhatsApp jaisa chat system kaise ordered, durable aur live rehta hai. Niche "Play all" dabaiye aur browser pura chapter padh kar sunayega. Kisi bhi section par "Suniye" se wahin se shuru karein.
▶ Companion slides kholiyeTip: jo voice sabse natural lage wahi chuniye — ek Hindi (hi-IN) ya Indian-English (en-IN) voice aam taur par best chalti hai.
System ko karna kya hai Slide 2
Chalo chapter baarah shuru karte hain, ek chat system design karna. Sabse pehle asli twist samajh lo. Normal web mein client maangta hai aur server jawab deta hai. Chat mein ulta hai, server ko client ko jagana padta hai jaise hi koi doosra message bheje. Yahi ek baat poore design ko chalati hai. Features chhote hain par unke andar chhupe constraints bade hain. Do logon wali chat yaani one to one, group chat, online presence, message history, push notifications, aur multi-device sync. In sab mein asli mushkil text bhejna nahi hai, balki durability, ordering, presence at scale, aur offline reach hai.
Connection model chunna Slide 3
Ab connection model. Chat ki jaan uske push channel mein hai. Short polling mein client baar baar poochta hai kuch naya hai kya, aur zyadatar jawab khaali aate hain, yeh pura waste hai. Long polling mein server request ko tab tak roke rakhta hai jab tak message na aaye, thoda behtar par thread block hoti hai. SSE ek taraf ka stream hai, server se client, par client alag se bhejta hai. Aur WebSocket ek hi upgraded connection par dono taraf bytes bhejta hai, full duplex. Chat bidirectional hai isliye WebSocket jeet jaata hai, ek persistent connection per device. Long polling sirf fallback rehta hai jab network upgrade block kar de.
Chaar moving parts Slide 4
High level architecture mein chaar hisse hain. Chat service akela stateful tier hai, wahi live sockets ko pakadta hai. Ek load balancer sockets ke saamne khada hota hai, user id ke hisaab se sticky. Presence service heartbeat aur TTL se online status track karta hai, aam taur par Redis mein. Push service APNs aur FCM ke upar ek patli gateway hai. Aur storage ek append-only key-value store hai jo chat id se partition hota hai. Ek registry yaad rakhta hai ki kaunsa user kaunse server par hai. Fayda yeh ki har concern apni alag axis par scale karta hai.
User ko server se map karna Slide 5
Ab yeh sawaal, kisi user ka socket kis server par hai. Ek user ka connection kisi bhi waqt ek hi chat server par hota hai. Alice se Bob tak message bhejne ke liye pata hona chahiye ki Bob ka socket kahan hai. Isliye ek shared registry, Redis ya ZooKeeper, user se server ka mapping rakhta hai. Yeh entry ek TTL ke saath aati hai jo heartbeat se refresh hoti hai. Connect par server likhta hai, yeh user mere paas hai. Send par recipient ko lookup karo, agar local hai to seedha frame push karo, agar remote hai to holding server ko RPC karo. Aur agar server crash ho jaaye to TTL khatam ho jaata hai aur agla reconnect mapping ko khud theek kar deta hai.
Ek se ek message ka flow Slide 6
Ek se ek message ka flow do rules par tikka hai. Message deliver hone se pehle durable hona chahiye, aur acknowledge hone se pehle ordered hona chahiye. Chat server pehle store karta hai, phir sender ko sent ka ack deta hai, phir recipient ko route karta hai. Message ko ek central ID generator, jaise Snowflake, ek monotonic sortable id deta hai. Agar Bob online hai to uske socket par push ho jaata hai aur delivered ka ack wapas aata hai. Agar Bob offline hai to message uske inbox mein baitha rehta hai aur push notification fire hoti hai. Reconnect par Bob ka device apne cursor se aage ka sab kuch kheench leta hai.
Messages ko scale par store karna Slide 7
Storage mein reads aur writes conversation ke hisaab se skew hote hain, user ke hisaab se nahi. Isliye conversation hi locality ka unit hai. Chat id par partition karo aur ek chat ke saare messages ek node par ikatthe ho jaate hain, ek contiguous log ki tarah. Workload write-heavy hai, append-only hai, aur recent messages par biased hai, isliye ek wide-column key-value store jaise Cassandra ya DynamoDB fit baithta hai. Partition ke andar sort key message id hoti hai, ek Snowflake jiske upar ke bits timestamp hote hain. Iska matlab id se sort karna time se sort karna hi hai. Yahi property har device ko out of order frames se sahi sequence banane deti hai.
Ek sender se kayi readers Slide 8
Group chat mein sender ek baar publish karta hai. Chat service message ko ek baar conversation log mein likhta hai, jo canonical message id deta hai, phir har member ke liye ek per-recipient inbox mein ek reference daal deta hai. Har member apni raftaar se fetch aur ack karta hai. Bob abhi padh le, Liu kal padhe, phir bhi unread count aasan reh jaata hai. Yeh fan-out kuch sau members tak theek hai. Usse upar, jaise broadcast channels, model ulta kar do. Har ek ko copy dene ke bajaye members shared log se khud pull karein.
Online presence Slide 9
Online presence dekhne mein trivial lagta hai par scale karna sabse mushkil hai. Har device har kuch second mein heartbeat bhejta hai aur har contact real time mein jawab chahta hai. Mechanism hai heartbeat plus TTL. Server presence key ko ping interval se do ya teen guna TTL ke saath likhta hai, aur har heartbeat use refresh karta hai. Kaafi heartbeats miss ho jaayein to key khud expire ho jaati hai, user implicitly offline. Asli kharcha read fan-out hai. Ek user ke paanch sau contacts hon to sirf online dots dikhane ke liye paanch sau reads per second lag jaate hain. Isliye aggressive caching karo, sirf state transitions push karo, aur presence sirf visible contacts ke liye compute karo.
Read receipts, typing, delivery Slide 10
Read receipts, typing, aur delivery status, yeh signals chat ko zinda ehsaas dete hain. Akele saste hain par aggregate mein bhaari. Isliye inhe best-effort banao aur first-class message ki tarah store mat karo. Delivery status exception hai, iske teen durable states hain. Sent matlab server ne durably store kar liya. Delivered matlab kam se kam ek recipient device ne socket par receive kiya. Read matlab UI ne chat khol kar message id ack kiya, jise ek cursor ki tarah store karo, har message ka alag row nahi. Aur idempotency zaroori hai, har ack message id le kar chalta hai aur duplicate ko server no-op maanta hai. Rule simple hai, agar signal khona sirf annoying ho to best-effort, agar galat ho to durable.
Offline users ke liye push Slide 11
Jab koi socket zinda na ho, app ko OS ne maar diya ho sakta hai, aur use pahunchne ka ek hi rasta hai, platform ka push gateway. Push service jaan boojh kar chat path se alag hai. Ek async queue, ek worker pool, aur kya bhejna hai iska ek careful faisla. Chat service tez rehta hai kyunki wo kisi third-party gateway par block nahi hota. Device tokens expire hote hain, isliye workers ko unregistered responses handle karke dead tokens hataane padte hain. Aur cancel-on-read, agar phone reconnect karke message padh le push deliver hone se pehle, to worker chupchaap notification drop kar deta hai. Yeh wahi machinery hai jo chapter das, notification system, mein detail se hai.
Sab devices ko sync rakhna Slide 12
Ek account ek device se bandha nahi hota. Phone, laptop, aur web alag alag connect karte hain aur sabko ek jaisa message order aur read state dikhna chahiye, bina user kuch kiye. Trick yeh hai ki server har session ka lagbhag kuch yaad nahi rakhta. Har device apna cursor rakhta hai, matlab har chat ke liye maine aakhri kaunsa message dekha. Reconnect par device sirf apne cursor se aage ka sab maangta hai. Read state global hai, phone par padho to laptop ka badge saaf ho jaata hai. Incoming message har live socket par push hota hai, delivered tab flip hota hai jab koi ek device ack kare. Aur kyunki order global message id se fix hai, devices ko coordinate nahi karna padta, sab alag alag same log par converge kar jaate hain.
Chhah principles Slide 13
To chhah principles yaad rakho. Ek, WebSocket reedh ki haddi hai, ek persistent full-duplex connection per device sab kuch carry karta hai. Do, deliver karne se pehle persist karo, storage source of truth hai. Teen, conversation ke hisaab se partition karo, chat id partition key aur Snowflake message id sort key. Chaar, fan-out wahan karo jahan theek baithe, chhote groups copy karein, bade rooms pull karein. Paanch, presence sabse loud surface hai, hard cache karo aur sirf transitions bhejo. Aur chhah, offline ke liye pehle din se plan karo, push gateways, per-device cursors, aur idempotent acks.
Aage kya
Bas, yahi hai chapter baarah. Ek kaam karo, apni favourite chat app socho aur khud se poochho, jab main offline hoon to message kahan baitha rehta hai, aur jab main dobara connect karta hoon to kaise catch up hota hai. Ek line mein bolo, server push karta hai, storage source of truth hai, aur cursor sab kuch sync rakhta hai. Method ko reflex bana lo, yahi sabse zaroori hai. Koi cheez confuse kare to mujhse pooch lena. Agle chapter mein hum ek search autocomplete system design karenge.