01सिर्फ़ 1:1 chat, या groups भी — और एक group कितना बड़ा हो सकता है?
Users 1:1 और group chats में messages भेजते और पाते हैं। Groups करीब 100 participants पर capped हैं, जिससे प्रति message fan-out bounded रहता है।
मुफ़्त पूरी गाइड
मैसेजिंग सिस्टम
मैसेजिंग सिस्टम डिज़ाइन करें। इसमें WebSocket connection management at scale: a connection registry mapping user/device to the gateway instance holding their socket, Message delivery semantics:...
00
अभ्यास checkpoints
Interview की लय संक्षिप्त रहती है, ताकि page असली design निर्णयों पर ध्यान लगा सके.
- 01Scope स्पष्ट करें
- 02Requirements + scale
- 03API + data model
- 04Architecture बनाएँ
- 05Deep dive
- 06Trade-off निर्णय
01
Requirements जो design तय करते हैं
सिर्फ requirements मत बताइए — पूछिए। हर card एक design constraint को उस clarification सवाल से जोड़ता है जो आप architecture बनाने से पहले बोल सकते हैं.
Functional requirements
02जब मैं offline हूँ तब भेजे गए संदेशों का क्या होता है?
Offline रहते भेजे गए messages device के दोबारा connect होने पर deliver होते हैं। वे 30 दिन तक रखे जाते हैं। Server एक सीमित buffer वाला relay है, कोई स्थायी archive नहीं।
03प्रति उपयोगकर्ता एक फ़ोन, या हर device sync में?
उपयोगकर्ता media जोड़ सकते हैं, और उपयोगकर्ता का हर device sync में रहता है — हर device अपनी delivery state खुद track करता है।
04Read receipts और typing indicators — दायरे में?
Receipts हाँ: वे messages वाले उसी per-device delivery path पर सवार होते हैं। Typing indicators अस्थायी हैं। वे best effort हैं, और कभी store नहीं होते।
05क्या उपयोगकर्ता एक भेजे गए संदेश को सबके लिए delete कर सकते हैं?
Delete-for-everyone एक tombstone event है जो ठीक एक सामान्य message की तरह सफ़र करता है। जिन clients ने message पहले दिखा दिया था वे उसे वहीं replace कर देते हैं। Edits scope से बाहर रहते हैं।
06कोई बातचीत के बीच में group में जुड़ता या छोड़ता है — वे क्या देखते हैं?
किसी group में join या leave करना chat में एक ordered event है। जो join करते हैं उन्हें join बिंदु से आगे के messages मिलते हैं। जो leave करते हैं वे leave event पर मिलना बंद कर देते हैं। किसी को अधूरा history नहीं मिलता।
Scope से बाहरAudio और video calling · Business messaging और chatbots · Registration और profile management
Non-functional requirements
01एक online व्यक्ति तक संदेश कितनी तेज़ी से पहुँचना चाहिए?
End to end 500 ms से कम — chat या तो तुरंत महसूस होता है या टूटा हुआ लगता है।
02क्या कोई संदेश कभी चुपके से ग़ायब हो सकता है?
नहीं। Deliverability की guarantee है। किसी भी delivery कोशिश से पहले message टिकाऊ रूप से लिखा जाता है, इसलिए एक टूटा connection उसे देर करता है पर कभी नहीं खोता।
03हम किस scale के लिए design कर रहे हैं?
200M daily actives, हर एक दिन में ~20 संदेश, किसी भी क्षण लगभग आधे online।
04Servers संदेश की सामग्री कितने समय तक रखते हैं?
जरूरत से ज़्यादा नहीं: undelivered inbox पर 30-दिन का TTL (time-to-live), फिर ख़त्म।
05जब एक chat server मर जाता है तो क्या होता है?
इसके users किसी दूसरे server से दोबारा connect होते हैं और inbox से sync कर लेते हैं। Delivery state server की memory में नहीं, storage में रहती है, इसलिए कोई message नहीं खोता।
पूछते रहिए — interview एक बातचीत है
असली interview एक साफ list से कहीं गहरा probe करते हैं. ये scope सवाल उन्हें अलग करते हैं जो problem को कुरेदते हैं बनाम जो रटते हैं.
- Group size की सीमा — सैकड़ों या हज़ारों? fan-out design इसी पर टिका है।
- प्रेषक जो ack देखता है वह "server को delivered" है या "device को delivered"?
- प्रति खाते कितने devices sync में रहने चाहिए?
- क्या संदेश इतिहास एक स्थायी archive है, या 30-दिन का relay buffer?
- क्या end-to-end encryption दायरे में है? यह बदलता है कि server क्या store कर सकता है।
02
वे numbers जो architecture निर्णय मजबूर करते हैं
हर estimate को एक दबाव मानिए जो किसी component को justify करता है: cache, queue, partition, replica, worker pool, या fallback path.
संदेश लिखने की दर
200M सक्रिय उपयोगकर्ता × ~20 संदेश/दिन200M × 20 = 4B संदेश/दिन; 4B ÷ 86,400 s ≈ 46K msg/s भेजे गए; group fan-out ×2-3 ≈ 100K writes/s
Message और Inbox को write-optimized storage चाहिए (LSM log-structured merge trees / wide-column)। Fan-out का काम participants की संख्या के साथ बढ़ता है, इसीलिए groups capped हैं।
समवर्ती connections
200M daily actives, किसी भी क्षण लगभग आधे online200M × ~50% ≈ 100M खुले WebSocket connections
Persistent sockets के साथ, gateway fleet का size connection count तय करता है, request rate नहीं।
प्रति gateway connections
प्रति दमदार gateway box ~1M समवर्ती WebSocket connections100M समवर्ती online ÷ 1M ≈ 100+ gateways
उपयोगकर्ता gateways पर hash होते हैं (consistent hashing + registry) ताकि message routing सही box ढूँढ सके।
Offline inbox आकार
30-दिन TTL, प्रति संदेश reference ~1KB1,000 undelivered संदेश भी ≈ प्रति निष्क्रिय उपयोगकर्ता 1 MB
TTL backstop को छोटा रखती है। लंबे समय से सोए devices अपना history इसके बजाय Message store से resync करते हैं।
निर्णय उदाहरण
Numbers
एक सेकंड में एक लाख writes, एक साथ दस करोड़ लोग online, और एक वादा: आधे सेकंड से कम, और कभी चुपके से कुछ नहीं खोया।
मेरी पसंद
Gateways को stateless रखो — वे बस sockets पकड़ते और forward करते हैं। हर message किसी भी push से पहले Message store और हर recipient के Inbox में लिखा जाता है, इसलिए कुछ भी सिर्फ़ memory में नहीं रहता। Cross-server delivery user ID से partition किए pub/sub पर सवार होती है, इसलिए हर gateway सिर्फ़ अपने users को subscribe करता है। Order server receipt time है; chat में, तेज़ होना पूरी तरह ordered होने से बेहतर है।
बचें
जो मैं नहीं करूँगा: undelivered messages को gateway memory में रखना। एक crash और वे गए, जो core वादा तोड़ देता है। मैं pub/sub को chat ID से भी partition नहीं करूँगा। एक व्यस्त group एक hot partition बन जाता, इसलिए user से partition करो। और मैं असली per-partition message rate नापे बिना sharding layers नहीं जोड़ूँगा। बहुत जल्दी sharding capacity नहीं, failure modes जोड़ती है।
कब बदलें
अगर end-to-end encryption scope में आ जाए, तो server सिर्फ़ ciphertext का एक अंधा router रह सकता है। तब Inbox और multi-device sync per-device message copies और client-held keys पर चले जाते हैं।
03
Architecture path
पहले एक पूरी तस्वीर, फिर हर path को अपना अलग diagram — write path और read path अलग traffic ढोते हैं और अलग components justify करते हैं.
पूरी तस्वीर
Overview — हर component
पहले टिकाऊ write, फिर delivery। Gateways stateless socket-holders हैं। Registry जानता है कि कौन कहाँ connected है, और offline devices को socket frame की बजाय एक push मिलती है।
Path 1
Send path — पहले durable, फिर fan out
Sender का ack टिकाऊ write के बाद fire होता है। फिर pub/sub हर उस gateway तक पहुँचती है जो किसी recipient device को पकड़े है। एक चूका हुआ publish safe है — inbox के पास वह पहले से है।
Path 2
Reconnect path — inbox खाली करो
Reconnect पर client अपना inbox drain करता है और sequence numbers की तुलना करता है। रास्ते में जो कुछ छूटा वह pull होता है, फिर real-time delivery फिर से शुरू हो जाती है।
04
API और data model
optimize करने से पहले contract को inspectable बनाइए: endpoints, entities, ownership, retries, और state.
WSsendMessage { chat_id, body, attachments[] }
res{ message_id, status } — ack after durable write
इस ack का मतलब है "stored", "delivered" नहीं — durability पहले, delivery बाद में।
WSnewMessage → client { chat_id, sender, body }
resclient replies RECEIVED
हर प्रतिभागी के हर online device को persistent connection पर push किया जाता है।
POST/attachments
req{ body: presigned upload }
res200 { attachment_id, url }
Media presigned URL के ज़रिए blob storage में जाता है; संदेश सिर्फ़ अपारदर्शी reference ले जाते हैं।
WSheartbeat every 10-30 s (piggybacks last sequence)
resclient compares and syncs gaps
Heartbeats मृत connections का पता लगाते हैं और साथ ही gap-detection channel के रूप में भी काम करते हैं।
Core entities
Chatchat_id (PK) · participants (≤100) · name
Messagemessage_id (PK) · chat_id · sender_id · body · attachments · server_ts
Server receipt timestamp के अनुसार क्रमित और प्रदर्शित — उपयोगकर्ता संदेशों को सही भेजने-क्रम में देखने के बजाय जल्दी देखना पसंद करेंगे।
Inboxuser_id (PK) · message_id · ttl_30d
Durability का backstop: किसी भी push प्रयास से पहले लिखा जाता है, reconnect पर खाली किया जाता है।
Clientuser_id (PK) · client_id · last_seen
एक उपयोगकर्ता, कई devices (~3 सीमा) — delivery per client track होती है, per user नहीं।
05
Deep dive दिशाएँ
interview के आखिरी एक-तिहाई के लिए एक lane चुनें. हर lane आपको topic, वह interviewer सवाल जिसका जवाब देना है, और बचने वाला failure mode देती है.
दस करोड़ खुले sockets
Ask
करोड़ों उपयोगकर्ता persistent connections कैसे रखते हैं, और एक संदेश अपने प्राप्तकर्ता को रखने वाला एक gateway कैसे ढूँढता है?
Answer
हर gateway ~1M sockets पकड़ता है; registry user → gateway map रखता है, और user ID से partition हुआ pub/sub संदेश सिर्फ़ उसी gateway तक पहुँचाता है जिसके पास recipient है।
बचें
हर संदेश को हर gateway पर broadcast करना — gateways को सिर्फ़ अपने जुड़े उपयोगकर्ताओं पर subscribe करो।
प्राप्तकर्ता offline है
Ask
संदेश कहाँ इंतज़ार करता है, कितनी देर, और जिस पल वे reconnect करते हैं क्या होता है?
Answer
संदेश recipient के durable inbox में इंतज़ार करता है (30-दिन TTL); reconnect पर client backlog खींच लेता है, बीच में push notification service सोए devices को जगाती है।
बचें
durability के लिए pub/sub पर भरोसा करना — यह at-most-once है; inbox write पहले आना चाहिए।
दो फ़ोन, एक खाता
Ask
एक उपयोगकर्ता अपने laptop पर एक संदेश पढ़ता है। उनके फ़ोन को क्या जानना ज़रूरी है, और per-device state कैसे track होती है?
Answer
Delivery और read state device के हिसाब से track होते हैं, user के नहीं; हर device अपने cursor से sync करता है, तो फ़ोन ठीक वही खींचता है जो उसने नहीं देखा।
बचें
delivery को per client के बजाय per user track करना — दूसरा device चुपके से संदेश चूक जाता है।
संदेश क्रम से बाहर आते हैं
Ask
दो संदेश अलग gateways से दौड़ते हैं। प्राप्तकर्ता किस क्रम में देखता है, और वह स्वीकार्य क्यों है?
Answer
क्रम हर conversation में server receipt time है और clients उसी timestamp से दिखाते हैं; gateways के बीच की क्षणिक race दिखती नहीं, जबकि global order के लिए रुकना वह latency देता है जो users सचमुच महसूस करते हैं।
बचें
global order थोपने के लिए delivery रोकना — उपयोगकर्ता सही क्रम से तेज़ी पसंद करते हैं।
एक gateway बातचीत के बीच मर जाता है
Ask
दस हज़ार उपयोगकर्ता एक साथ गिर जाते हैं। वे क्या खोते हैं, और कितनी जल्दी फिर पूरे होते हैं?
Answer
कुछ नहीं खोता — undelivered संदेश durable inboxes में हैं, gateway memory में नहीं। Clients दूसरे gateway से जुड़ते हैं, और 10-30 s की heartbeat में आया latest sequence number हर client को अपना gap दिखाकर उसे भरने देता है।
बचें
कोई भी design जहाँ gateway memory किसी undelivered संदेश की एकमात्र प्रति हो।
अभ्यास के लिए तैयार?
मैसेजिंग सिस्टम को ज़ोर से समझाइए और अपनी व्याख्या पर AI scoring पाइए.