टीएल;डीआर
- समस्या: बड़े पैमाने की वास्तुकला (आर्किटेक्चर) तैयार करने के लिए उपलब्धता, थ्रूपुट और परिचालन जटिलता के बीच संतुलन बनाना आवश्यक है।
- मुख्य निष्कर्ष: बिल्कुल शुरुआती लोगों के लिए चैट सिस्टम डिज़ाइन: लाइव ऑनलाइन पथ बनाम इतिहास स्टोरेज, १:१ और छोटे ग्रुप, प्रेजेंस, डिलीवरी टिक, और पूरे डिज़ाइन को दोस्त को कैसे समझाएँ।
- परिणाम: उत्पादन वातावरण में विफलता से निपटने और प्रदर्शन लक्ष्यों को हासिल करने की सटीक रूपरेखा।
व्हाट्सऐप या आईमैसेज खोलो। एक लाइन टाइप करो। सेंड दबाओ। एक टिक दिखता है। कभी-कभी हरा डॉट कहता है कि दोस्त ऑनलाइन है। जादू लगता है। जादू नहीं है। दो पुराने विचार हैं, नई पोशाक में।
विचार १: वॉकी-टॉकी। जब दोनों लोग अभी जुड़े हों, सर्वर एक लाइव लाइन खुली रखता है ताकि शब्द एक सेकंड के अंश में पहुँच जाएँ।
विचार २: डाकघर। हर मैसेज एक गोदाम (डेटाबेस) में भी दर्ज होता है। जब कोई ऑफलाइन था, या बाद में दूसरे फ़ोन पर ऐप खोले, इतिहास हवा से नहीं, उसी गोदाम से आता है।
अगर इस पोस्ट से सिर्फ एक वाक्य याद रखना हो, तो यह रखो: लाइव कनेक्शन स्पीड के लिए है; मैसेज स्टोर सच्चाई के लिए है।
यह गाइड चैट सिस्टम डिज़ाइन वैसे सिखाती है जैसे एक धैर्यवान प्रोफेसर सिखाए: पहले साफ़ भाषा, फिर असली प्रोडक्ट व्यवहार, फिर इंटरव्यू के बॉक्स। हम मैसेंजर-स्टाइल प्रोडक्ट बाँधते हैं: १:१ चैट, छोटे ग्रुप, टेक्स्ट, ऑनलाइन प्रेजेंस, डिलीवरी टिक, और मल्टी-डिवाइस इतिहास। वेबसॉकेट के तार-स्तरीय विवरण (हैंडशेक, हार्टबीट, रीकनेक्ट) के लिए देखें रियल-टाइम ऐप्स के लिए वेबसॉकेट। यहाँ हम प्रोडक्ट आर्किटेक्चर पर रहते हैं।
हम क्या बना रहे हैं?
बॉक्स और तीर से पहले प्रोडक्ट पिन करो। इंटरव्यू तब बिगड़ते हैं जब लोग डिस्कॉर्ड-स्केल चैनल गढ़ लें और सवाल सिर्फ “दोस्तों वाला व्हाट्सऐप” हो।
| सवाल | इस पोस्ट का डिफ़ॉल्ट जवाब |
|---|---|
| १:१, ग्रुप, या दोनों? | दोनों |
| ग्रुप साइज़ | लगभग १०० सदस्य अधिकतम |
| क्लाइंट | फ़ोन और वेब |
| स्केल उदाहरण | रोजाना करोड़ों यूज़र (आर्डर ऑफ़ मैग्नीट्यूड) |
| मैसेज टाइप | पहले टेक्स्ट; बाद में फ़ोटो |
| इतिहास | लंबे समय तक रखना |
| एक अकाउंट फ़ोन + लैपटॉप | हाँ |
| एंड-टू-एंड एन्क्रिप्शन | जब तक न पूछें, स्कोप से बाहर |
| ऑफलाइन पर सूचना | हाँ (पुश नोटिफ़िकेशन) |
यूज़र को क्या कर पाना चाहिए
१. दोनों ऑनलाइन हों तो १:१ मैसेज तेज़ी से भेजना-पाना। २. छोटे ग्रुप में चैट। ३. कौन ऑनलाइन/ऑफलाइन है देखना (प्रेजेंस)। ४. ऐप खोलकर पुराने मैसेज लोड करना। ५. कई डिवाइस पर सिंक रहना। ६. ऑफलाइन पर पुश पाना, फिर ऐप खोलकर कैच-अप।
जब तक न पूछें, यह डिज़ाइन नहीं: वॉइस कॉल, दस लाख लोगों वाले चैनल, रिएक्शन, पूरे इतिहास पर सर्च, पूरा E२E क्रिप्टो। स्कोप से बाहर नाम लेकर बात ईमानदार रखो।
मूल मानसिक मॉडल: वॉकी-टॉकी और डाकघर
वॉकी-टॉकी = ऑनलाइन पथ
दो दोस्त एक ही चैनल पर वॉकी-टॉकी लेकर सोचो। बटन दबाओ, बोलो, छोड़ो। दूसरा सुनता है अगर वह अभी सुन रहा हो।
चैट में:
- फ़ोन चैट सर्वर से एक लंबे समय तक खुला कनेक्शन रखता है (आमतौर पर वेबसॉकेट)।
- जब तुम “आ रहा हूँ” भेजते हो, सर्वर दोस्त के खुले कनेक्शन पर वह टेक्स्ट तुरंत पुश कर सकता है।
- हर सेकंड “कोई नया मैसेज?” पूछने की ज़रूरत नहीं। जब कुछ होता है, सर्वर बोलता है।
यही लाइव तार है जिसकी वजह से चैट तुरंत लगती है। इसी वजह से चैट सर्वर कठिन भी हैं: लाखों फ़ोन एक साथ सॉकेट खुला रख सकते हैं।
डाकघर = इतिहास स्टोरेज
वॉकी-टॉकी पिछले हफ़्ते की बातचीत के काम नहीं आती। उसके लिए फ़ाइलिंग सिस्टम चाहिए।
चैट में:
- हर स्वीकार किया गया मैसेज ड्यूरेबल स्टोरेज में लिखा जाता है (बहुत से छोटे ऐपेंड के लिए बनी डेटाबेस)।
- दोस्त ऑफलाइन था तो भी मैसेज स्टोर में रहता है।
- ऐप खुलने पर क्लाइंट पूछता है: “message id X के बाद सब दो।”
- फ़ोन से लैपटॉप बदलो तो लैपटॉप वही स्टोर से इतिहास लाता है।
अंगूठा-नियम
| पथ | काम | अगर अकेले इस पर भरोसा करो तो |
|---|---|---|
| लाइव कनेक्शन (वॉकी-टॉकी) | ऑनलाइन रहते तेज़ डिलीवरी | डिस्कनेक्ट रहते भेजी चीज़ें छूट जाती हैं |
| मैसेज स्टोर (डाकघर) | टिकाऊ इतिहास और कैच-अप | बिना पुश सिर्फ पुल पर बहुत धीमा |
प्रोडक्शन चैट दोनों इस्तेमाल करती है। लाइव पुश गति है। स्टोर सच्चाई का स्रोत है। कमज़ोर नेटवर्क पर पुश खो जाए तो स्टोर से अगला सिंक गैप भर देता है।
फ़ोन “लाइन पर” कैसे रहता है?
सामान्य वेब रिक्वेस्ट पोस्टकार्ड भेजकर जवाब का इंतज़ार जैसा है। लॉगिन या प्रोफ़ाइल के लिए ठीक। चैट के लिए खराब।
चैट में जब तुम्हारे लिए मैसेज आए तो सर्वर को पहले बोलना होता है। आम विकल्प:
| तरीका | शुरुआती सार | चैट के लिए? |
|---|---|---|
| शॉर्ट पोलिंग | ऐप हर कुछ सेकंड पूछे “कुछ नया?” | बेकार खर्च; अक्सर “नहीं” |
| लॉन्ग पोलिंग | ऐप पूछे और सर्वर कुछ आने तक पकड़े रखे | चलता है; स्केल पर अजीब |
| वेबसॉकेट | छोटा हैंडशेक के बाद दोनों तरफ़ खुला लंबा पाइप | डिफ़ॉल्ट हाँ |
| एचटीटीपी रेस्ट | सामान्य रिक्वेस्ट-रिस्पॉन्स | लॉगिन, इतिहास पेज, सेटिंग |
कई प्रोडक्ट मैसेज वेबसॉकेट पर भेजते हैं और उबाऊ काम (साइनअप, फ्रेंड लिस्ट, पुराना इतिहास) एचटीटीपी पर रखते हैं। अहम बाँट:
- स्टेटलेस एचटीटीपी एपीआई: कोई भी सर्वर जवाब दे; स्केल आसान।
- स्टेटफुल चैट गेटवे: हर लाइव फ़ोन एक चैट नोड से चिपकता है जो उसका सॉकेट रखता है।
स्टिकी कनेक्शन का मतलब मैप चाहिए: “यूज़र B अभी चैट सर्वर ७ पर, डिवाइस फ़ोन।” यह मैप तेज़ स्टोर में रहता है (अक्सर रेडिस)। बिना इसके सर्वर १ को नहीं पता B को कैसे पुकारे जो सर्वर ७ पर है।
बड़ी तस्वीर आर्किटेक्चर (फिर भी सरल)
तीन तरह के टुकड़े, पचास लोगो नहीं।
१. उबाऊ प्रोडक्ट एपीआई (स्टेटलेस)
ऑथ, प्रोफ़ाइल, कॉन्टैक्ट लिस्ट, बातचीत सूची, इतिहास फ़ेच। सामान्य लोड बैलेंसर के पीछे। ट्रैफ़िक बढ़े तो मशीनें जोड़ो।
२. चैट सर्वर (स्टेटफुल)
वेबसॉकेट सेशन रखते हैं। नए मैसेज स्वीकार करते हैं। मैसेज, “टाइपिंग…” और प्रेजेंस इवेंट पुश करते हैं। यूज़र कहाँ कनेक्टेड है ढूँढते हैं।
३. सहायक सिस्टम
| टुकड़ा | साधारण शब्दों में काम |
|---|---|
| मैसेज स्टोर | पूरे चैट इतिहास का डाक गोदाम |
| ID जेनरेटर | यूनिक मैसेज id, बेहतर हो तो समय-क्रम के करीब |
| सेशन मैप | user_id → कौन सा चैट सर्वर और कौन से डिवाइस |
| प्रेजेंस स्टोर | ऑनलाइन/ऑफलाइन, आखिरी सक्रिय समय |
| क्रॉस-सर्वर बस | दूसरे नोड को कहे “यह यूज़र B को पहुँचाओ” |
| पुश सर्विस | लाइव सॉकेट न हो तो लॉक स्क्रीन नोटिफ़ |
| ऑब्जेक्ट स्टोरेज (बाद में) | फ़ोटो और वीडियो |
फ़ोन / वेब ──HTTP──► API (ऑथ, इतिहास पेज)
फ़ोन / वेब ──WS────► चैट सर्वर ──► बस ──► अन्य चैट सर्वर
│
├── मैसेज स्टोर (सच्चाई)
├── सेशन + प्रेजेंस मैप
└── पुश प्रोवाइडर (अगर ऑफलाइन)
ऑनलाइन होना: सही वॉकी-टॉकी टॉवर से जुड़ना
ऐप खुलने पर:
१. क्लाइंट एपीआई से लॉगिन करके छोटा जीवन वाला टोकन लेता है। २. सर्विस डिस्कवरी जवाब देती है: “अपना वेबसॉकेट इस चैट होस्ट से जोड़ो” (स्वस्थ, ओवरलोड नहीं, बेहतर पास का रीजन)। ३. क्लाइंट उस टोकन के साथ वेबसॉकेट खोलता है। ४. चैट सर्वर टोकन जाँचता है, सेशन मैप में एंट्री लिखता है, तुम्हें ऑनलाइन मार्क करता है, और हार्टबीट सुनना शुरू करता है।
अगर वह चैट सर्वर मर जाए, डिस्कवरी उसे विज्ञापित करना बंद कर देती है। क्लाइंट बैकऑफ़ के साथ फिर जुड़ते हैं और स्वस्थ नोड पर पहुँचते हैं। बिना ack वाले मैसेज फ़ोन के लोकल आउटबॉक्स में इंतज़ार करते हैं।
डिस्कवरी को ऐसे सोचो: ऑपरेटर जो तुम्हें खाली रेडियो टॉवर देता है, न कि सबको एक टूटे टॉवर पर ठूँस देता है।
हर मैसेज में क्या स्टोर होता है?
चैट लिखतें ज़्यादातर ऐपेंड हैं: बातचीत के अंत में नई पंक्तियाँ। व्यवहारिक रिकॉर्ड कुछ ऐसा:
| फ़ील्ड | क्यों |
|---|---|
message_id |
यूनिक id, बेहतर हो तो समय से सॉर्ट हो |
conversation_id |
कौन सा थ्रेड |
sender_id |
किसने भेजा |
body |
टेक्स्ट |
created_at |
सर्वर समय |
type |
टेक्स्ट, सिस्टम नोटिस, आदि |
client_msg_id (वैकल्पिक) |
नेटवर्क रिट्राई पर डबल सेंड रोकता है |
महत्वपूर्ण एक्सेस पैटर्न:
१. बातचीत खोलना: उस conversation_id के आखिरी N मैसेज, फिर स्क्रॉल पर पुराने।
२. डिवाइस कैच-अप: इस यूज़र के लिए कर्सर X से नए सब।
३. छोटे ग्रुप फैन-आउट: अक्सर हर सदस्य के इनबॉक्स में कॉपी या पॉइंटर, ताकि हर फ़ोन अपना मेल ही पढ़े।
इंटरव्यू में अक्सर key-value या wide-column कहानी पसंद आती है (पार्टिशन बातचीत या प्राप्तकर्ता इनबॉक्स से), क्योंकि लिखने का वॉल्यूम ऊँचा और एक्सेस की से, जटिल जॉइन से नहीं। छोटे स्केल पर अच्छे इंडेक्स वाला एसक्यूएल चलता है; कहो कब उससे आगे जाओगे।
आइडेम्पोटेंसी: नेटवर्क ब्लिप पर फ़ोन वही मैसेज दो बार भेज सकता है। (sender_id, client_msg_id) से डाकघर एक चिट्ठी पर मुहर लगाए, दो कॉपी नहीं।
१:१ फ़्लो: A, B को मैसेज भेजता है
A चैट सर्वर १ पर है। B चैट सर्वर २ पर है।
1. A → वेबसॉकेट → सर्वर 1: {to: B, body, client_msg_id}
2. सर्वर 1 जाँच: बात करने की अनुमति? रेट लिमिट ठीक?
3. message_id दो, मैसेज स्टोर में लिखो
4. A को ack → UI “भेजा” दिखाए
5. सेशन मैप में B ढूँढो
6a. B ऑनलाइन: बस से सर्वर 2 को बताओ → B के सॉकेट पर पुश → B की ऐप ack दे तो “डिलीवर्ड”
6b. B ऑफलाइन: पुश नोटिफ़ कतार; मैसेज स्टोर में सिंक का इंतज़ार
7. रीड: B की ऐप “message_id तक देखा” रिपोर्ट करे → स्टोर अपडेट → A के डिवाइस को सूचना
क्रम: एक बातचीत के अंदर क्रम रखो (या कम से कम प्रति भेजने वाले)। पूरी दुनिया के हर चैट का ग्लोबल क्रम महँगा और बेकार है।
सच्चाई बनाम गति: बस लाइव पुश गिरा दे तो भी B स्टोर से सिंक पर मैसेज पाएगा। लाइव फैन-आउट ड्यूरेबल स्टोरेज का विकल्प नहीं।
डिलीवरी टिक: हर निशान का असली मतलब
यूज़र टिक को भावना की तरह पढ़ते हैं। इंजीनियर को उन्हें इवेंट से जोड़ना चाहिए।
| जो दिखे | सिस्टम का मतलब |
|---|---|
| घड़ी / भेज रहा / फेल | अभी सिर्फ फ़ोन पर; सर्वर ने स्वीकार नहीं किया |
| भेजा (एक टिक) | सर्वर ने मैसेज लिखा और message_id लौटाया |
| डिलीवर्ड (दो टिक) | प्राप्तकर्ता के कम से कम एक डिवाइस तक पहुँचा (या फ़ेच के बाद डिलीवर्ड मार्क) |
| रीड (नीला / भरा) | प्राप्तकर्ता की क्लाइंट ने “देखा” रिपोर्ट किया |
इंटरव्यू में टिकने वाले नोट:
- भेजा परसिस्ट के बाद सर्वर-अथॉरिटेटिव है। सिर्फ इसलिए “भेजा” न दिखाओ कि यूआई ने आशावादी रंग भर दिया।
- डिलीवर्ड को लाइव पथ पर क्लाइंट ack चाहिए, या स्टोर से पुल के बाद ack। मल्टी-डिवाइस पर नियम चुनो: “कोई भी डिवाइस” आम है।
- रीड अक्सर मिलाया जाता है: “id X तक पढ़ा” न कि हर स्क्रॉल पर प्रति मैसेज एक रो।
- सेंड पथ को दूसरे के पढ़ने पर मत रोक। स्टेटस मुख्य पथ के बगल में चलता है।
वॉकी-टॉकी उपमा: “भेजा” = डाकघर ने चिट्ठी स्वीकार की। “डिलीवर्ड” = उनके मेलबॉक्स या हाथ तक पहुँची। “रीड” = उन्होंने खोली।
छोटे ग्रुप: एक पुकार, कई मेलबॉक्स
लगभग १०० लोगों तक के ग्रुप के लिए व्यवहारिक मॉडल है लिखते समय फैन-आउट प्रति-यूज़र इनबॉक्स में:
१. A group_id पर भेजता है।
२. सर्वर सदस्य सूची लाता है (कैश रखो)।
३. ग्रुप इतिहास के लिए कैनॉनिकल मैसेज एक बार लिखो।
४. हर सदस्य के सिंक इनबॉक्स में कॉपी या पॉइंटर रखो।
५. हर ऑनलाइन सदस्य के चैट सर्वर पर लाइव पुश।
६. ऑफलाइन को पुश नोटिफ़; बाद में सिंक।
छोटे N पर कॉपी क्यों?
- हर क्लाइंट कैच-अप के लिए सिर्फ अपना इनबॉक्स पढ़े। सरल मॉडल।
- आंशिक डिलीवरी और मेंबरशिप अजीबोगरीब बातें प्रति यूज़र आसान।
- लागत प्रति मैसेज O(सदस्य) स्टोरेज और काम। १०० पर ठीक। १,००,००० पर दर्द।
विशाल चैनल (सार्वजनिक डिस्कॉर्ड सोचो) पर मॉडल पलटो: चैनल पर एक बार स्टोर, सदस्य पुल या स्ट्रीम सब्सक्राइब करें, प्रेजेंस लगभग-सही हो। यह ट्रेड-ऑफ़ ज़ोर से बोलो। यह मत मानो कि १:१ डिज़ाइन सिर्फ “सर्वर जोड़कर” दस लाख वाले रूम तक पहुँच जाएगा।
मेंबरशिप बदलाव: नया जॉइनर जॉइन से पहले का इतिहास देखे? यह प्रोडक्ट नियम है। ज़िक्र करो।
प्रेजेंस: हरे और भूरे डॉट
“ऑनलाइन” लॉगिन पर एक बार पेंट किया बूलियन नहीं। मोबाइल नेटवर्क पलक झपकाते हैं। भोला डिज़ाइन हर छोटे डिस्कनेक्ट पर ऑफलाइन कर दे तो कॉन्टैक्ट लिस्ट झपकती रहेगी।
काम करने वाले सिग्नल
| इवेंट | प्रेजेंस प्रभाव |
|---|---|
| वेबसॉकेट लॉगिन सफल | ऑनलाइन का उम्मीदवार |
| हर कुछ सेकंड हार्टबीट | ऑनलाइन बने रहो |
| साफ़ लॉगआउट | तुरंत ऑफलाइन |
| ग्रेस विंडो (उदाहरण: ३०s) से ज़्यादा मिस्ड हार्टबीट | ऑफलाइन |
| ग्रेस के अंदर छोटा नेटवर्क ब्लिप | ऑनलाइन रहो |
कुछ ऐसा स्टोर करो:
user_id → { status: online|offline, last_active_at, devices: [...] }
अक्सर रेडिस में, हार्टबीट से रिफ़्रेश होने वाला टीटीएल।
किसे बताना है?
सामान्य फ्रेंड लिस्ट पर, इच्छुक दोस्तों (या उस प्रोफ़ाइल को देख रहे लोगों) को प्रेजेंस बदलाव पब्लिश करो। उनके चैट सर्वर छोटा “अब ऑनलाइन” पुश करें।
विशाल ग्रुप में हर ऑनलाइन पलक पर १,००,००० लोगों को स्पैम मत करो। सदस्य सूची खोलते समय प्रेजेंस लाओ; माँग पर रिफ़्रेश।
प्रेजेंस एवेंटुअली कंसिस्टेंट है। कुछ सेकंड ग़लत होना सिस्टम पिघलाने से बेहतर है।
उपमा: हरी बत्ती का मतलब “मैं अभी चैनल पर सुन रहा हूँ”, यह नहीं कि “दुनिया में कहीं मेरा रेडियो है”।
मल्टी-डिवाइस: एक व्यक्ति, दो रेडियो
फ़ोन और लैपटॉप दोनों खुले। हर डिवाइस एक कर्सर रखता है: उसने जो आखिरी message id लागू किया।
कनेक्ट या रिज़्यूम पर:
१. लाइव कनेक्शन खोलो (और/या एचटीटीपी सिंक)।
२. पूछो: मेरे लिए message_id > cursor वाले मैसेज।
३. लागू करो, कर्सर आगे बढ़ाओ, यूआई पेंट करो।
दोनों लाइव हों तो सेशन मैप प्रति यूज़र कई कनेक्शन रखता है। हर कनेक्शन पर फैन-आउट पुश ताकि दोनों स्क्रीन बिना अगले पुल के अपडेट हों। कर्सर स्लीप, एयरप्लेन मोड और मारी गई ऐप ठीक करता है।
घबराहट वाली शब्दावली के बिना स्केल
कनेक्शन
हर चैट नोड खुले सॉकेट का एक हिस्सा रखता है। कनेक्शन गिनती (और प्रति सॉकेट मेमोरी) अक्सर सीपीयू से पहले दर्द देती है। हॉरिज़ॉन्टल स्केल = और चैट नोड + डिस्कवरी जो नए लॉगिन बाँटे। डिप्लॉय पर पुराने नोड ड्रेन; क्लाइंट फिर जुड़ें।
लाइव एडजस्ट करने लायक इंटरव्यू गणित:
- ५ करोड़ दैनिक यूज़र।
- पीक कन्करेंट कनेक्शन DAU का अंश हो सकता है (उदाहरण: एक साथ १ करोड़ ऑनलाइन)।
- अगर हर कनेक्शन बफ़र और सेशन स्टेट के लिए लगभग १० KB सर्वर रैम ले, तो कनेक्शन मेमोरी पूरे फ़्लीट पर कई दस GB है, एक लैपटॉप पर नहीं।
मैसेज पथ
- स्टोर को बातचीत या प्राप्तकर्ता इनबॉक्स से पार्टिशन करो।
- हॉट पथ: ऑथराइज़ → id → परसिस्ट → “भेजा” ack → असिंक फैन-आउट।
- पुश नोटिफ़ और एनालिटिक्स को क्रिटिकल ack पथ से बाहर रखो।
नाम लेने लायक फ़ेल्यर
| फ़ेल्यर | बचाव |
|---|---|
| चैट नोड मर जाए | क्लाइंट रीकनेक्ट + डिस्कवरी; स्टोर से कैच-अप |
| नोड के बीच बस ड्रॉप | स्टोर + सिंक ही सच्चाई |
| डबल सेंड | client_msg_id आइडेम्पोटेंसी |
| हॉट ग्रुप | मेंबर कैश; रेट लिमिट; बैकप्रेशर |
| प्रेजेंस तूफ़ान | हार्टबीट ग्रेस; बड़े रोस्टर पर ऑन-डिमांड |
| विशाल मैसेज | गेटवे पर साइज़ कैप |
एक साँस में कंसिस्टेंसी
- सर्वर ack के बाद: मैसेज टिकाऊ है और दिखेगा (पुश या बाद का सिंक)।
- लाइव डिलीवरी: बेस्ट-एफर्ट तेज़ पथ।
- रीड रसीद और प्रेजेंस: एवेंटुअल।
यह बाँट आंशिक फ़ेल्यर में सेंड बटन को ईमानदार रखता है।
सुरक्षा और दुरुपयोग (इंटरव्यू गहराई)
- वेबसॉकेट ऑथेंटिकेट करो; टोकन रिफ़्रेश बिना लापरवाही से पाइप गिराए।
- हर सेंड ऑथराइज़ करो (ब्लॉक लिस्ट, ग्रुप मेंबरशिप)।
- प्रति यूज़र और प्रति ग्रुप रेट लिमिट।
- बॉडी साइज़ कैप।
- वायर पर TLS (WSS)। स्टोर में at-rest एन्क्रिप्शन। पूरा E२E अलग डिज़ाइन है (हर डिवाइस पर कुंजी)।
- सर्वर-साइड फैन-आउट का मतलब सर्वर प्लेनटेक्स्ट पढ़ सकता है जब तक E२E न चुनो। बताओ तुम किस दुनिया में हो।
व्हाइटबोर्ड पर बचाव योग्य डिज़ाइन
प्रोडक्ट: बड़े स्केल मैसेंजर स्टाइल, १:१ + ग्रुप ≤१००, टेक्स्ट, प्रेजेंस, मल्टी-डिवाइस, ऑफलाइन पर पुश।
टुकड़े:
१. एचटीटीपी एपीआई क्लस्टर (ऑथ, प्रोफ़ाइल, इतिहास)। २. स्वस्थ चैट एंडपॉइंट के लिए डिस्कवरी। ३. चैट गेटवे फ़्लीट (वेबसॉकेट + सेशन अपडेट)। ४. ID जेनरेटर। ५. मैसेज स्टोर (ऐपेंड और बातचीत-वार रीड के लिए पार्टिशंड)। ६. सेशन और प्रेजेंस के लिए तेज़ स्टोर। ७. क्रॉस-नोड डिलीवर के लिए pub/sub या कतार। ८. पुश वर्कर (एपीएनएस / एफसीएम)।
१:१ सेंड: WS → वैलिडेट → id → परसिस्ट → sent ack → प्राप्तकर्ता नोड या पुश → डिलीवर्ड/रीड साइड इवेंट।
ग्रुप: वही, मेंबरशिप विस्तार और छोटे N पर प्रति-यूज़र इनबॉक्स फैन-आउट।
सिंक: स्टोर से प्रति डिवाइस कर्सर; सभी सक्रिय सेशन पर लाइव पुश।
ज़ोर से कहने वाले ट्रेड-ऑफ़:
- दोनों तरफ़ वेबसॉकेट क्लाइंट सरल करता है; एचटीटीपी सेंड + WS रिसीव भी चलता है।
- प्रति-यूज़र इनबॉक्स कॉपी छोटे ग्रुप सरल करती है; विशाल चैनल पर टूटती है।
- लाइव फैन-आउट ड्यूरेबल स्टोरेज का विकल्प नहीं।
- प्रेजेंस को हार्टबीट और ग्रेस चाहिए, कच्चे टीसीपी डिस्कनेक्ट इवेंट नहीं।
- सारे सॉकेट एक सर्वर पर खिलौना है, ग्लोबल चैट नहीं।
प्रोडक्शन चेकलिस्ट
- स्कोप: १:१, ग्रुप साइज़, मीडिया, एन्क्रिप्शन, रिटेंशन
- एचटीटीपी बनाम वेबसॉकेट बाँट साफ़
- डिस्कवरी सिर्फ स्वस्थ चैट नोड लौटाए
- सेशन मैप मल्टी-डिवाइस सपोर्ट करे
- मैसेज id यूनिक और मर्ज-फ्रेंडली
- क्लाइंट id से आइडेम्पोटेंट सेंड
- “भेजा” से पहले (या साफ़ सेमेंटिक्स के साथ) परसिस्ट
- मल्टी-डिवाइस के लिए डिलीवर्ड और रीड परिभाषित
- ऑफलाइन पुश पथ टेस्टेड
- प्रेजेंस हार्टबीट + ग्रेस विंडो
- ग्रुप फैन-आउट लागत सीमित (या बड़े N पर अलग मॉडल)
- एज पर रेट लिमिट और अधिकतम बॉडी साइज़
- डिप्लॉय और नोड मृत्यु के लिए ड्रेन और रीकनेक्ट कहानी
- मेट्रिक्स: कनेक्शन, सेंड QPS, ack लेटेंसी, फैन-आउट लैग, पुश सफलता, रीकनेक्ट दर
दोस्त को बताने वाला सार
चैट को दो जुड़े सिस्टम की तरह सोचो।
पहले, वॉकी-टॉकी नेटवर्क। जब तुम ऑनलाइन हो, फ़ोन चैट सर्वर से लाइव लाइन रखता है। मैसेज उसी लाइन से पुश होते हैं, इसलिए चैट तुरंत लगती है। हरे डॉट का मतलब “मैं अभी चैनल पर हूँ”, चुप हार्टबीट से रिफ़्रेश, ताकि टनल का छोटा ब्लिप तुम्हें ऑफलाइन न रंग दे।
दूसरा, डाकघर। हर स्वीकार मैसेज दर्ज होता है। टिक का मतलब: डाकघर ने स्वीकार किया (भेजा), उनके डिवाइस तक पहुँचा (डिलीवर्ड), खोला (रीड)। दोस्त सो रहा या ऑफलाइन था तो चिट्ठी स्टोर में रहती है। ऐप खोले, या दूसरा डिवाइस खोले, कर्सर से इतिहास खींचता है: “जो मेरे पास आखिरी है उसके बाद सब दो।”
एक-से-एक चैट एक चिट्ठी है, और जुड़े हों तो लाइव पुकार। छोटे ग्रुप बहुत से मेलबॉक्स कॉपी (या पॉइंटर) बनाते हैं ताकि हर व्यक्ति अपने इनबॉक्स से कैच-अप करे। विशाल सार्वजनिक रूम को अलग मॉडल चाहिए; छोटे-ग्रुप डिज़ाइन को हमेशा के लिए मत खींचो।
लाइव पुकार फेल हो तो भी गोदाम में चिट्ठी है। गति वॉकी-टॉकी है। सच्चाई डाकघर है। यही पूरा चैट सिस्टम एक साँस में।
समापन
चैट सिस्टम “वेबसॉकेट प्लस डेटाबेस” नहीं है। यह स्टिकी रियल-टाइम सेशन है, मैसेज का टिकाऊ ऐपेंड लॉग है, और फैन-आउट नियम जो ग्रुप साइज़ के साथ बदलते हैं, साथ में प्रेजेंस और सिंक ताकि मल्टी-डिवाइस जीवन और कमज़ोर नेटवर्क टूटे हुए नहीं, इरादतन लगें।
इंटरव्यू रीढ़: उबाऊ क्रड के लिए एचटीटीपी, लाइव तार के लिए वेबसॉकेट, सच्चाई के लिए स्टोर, तेज़ पथ के लिए पुश, छोटे ग्रुप के लिए प्रति-यूज़र इनबॉक्स, प्रेजेंस के लिए हार्टबीट। बाकी साइज़िंग, फ़ेल्यर हैंडलिंग, और प्रोडक्ट स्कोप है।
जब कोई पूछे “अगर ग्रुप में दस लाख सदस्य हों?” तो फैन-आउट मॉडल बदलो। सिर्फ वॉकी-टॉकी डिज़ाइन पर सर्वर जोड़कर उम्मीद मत करो।