एक साधारण लाइव चैट ने लगभग इस रिलीज़ को डुबो ही दिया था

एक बुनियादी लाइव चैट सिस्टम ने मेरी नवीनतम रिलीज़ को लगभग बर्बाद कर दिया था।

यह सुनने में सरल लगता है। आप पास के उपयोगकर्ताओं को दिखाते हैं और उन्हें बात करने देते हैं। लेकिन तकनीकी वास्तविकता बहुत कठिन है। मुझे लाइव चैट को जियोलोकेशन (geolocation) और एक रेटिंग सिस्टम के साथ जोड़ना पड़ा। इससे बैकएंड में भारी जटिलता पैदा हो गई।

आर्किटेक्चर:

• Frontend: React और TypeScript. • Backend: Express और WebSockets के साथ Node.js. • Database: उपयोगकर्ताओं और रेटिंग के लिए PostgreSQL. • Cache: सक्रिय सत्रों (active sessions) और उपस्थिति (presence) के लिए Redis.

जियोलोकेशन की समस्या

स्थान के आधार पर उपयोगकर्ताओं का मिलान करना आसान नहीं है। मुझे कई edge cases को संभालना पड़ा:

  • अक्षांश (latitude) और देशांतर (longitude) को स्टोर करना।
  • दूरी क्वेरी करने के लिए Postgres एक्सटेंशन का उपयोग करना।
  • उन उपयोगकर्ताओं को संभालना जो लोकेशन की अनुमति नहीं देते हैं।
  • जब कोई उपयोगकर्ता ऐप खोले बिना कहीं और चला जाता है, तो stale डेटा को मैनेज करना।

अगर मैं इसे फिर से करता, तो मैं लोकेशन कलेक्शन और मैचिंग को अलग-अलग सेवाओं (services) में विभाजित कर देता।

लाइव चैट की वास्तविकता

WebSockets रीयल-टाइम फीचर्स लाते हैं, लेकिन वे अराजकता भी लाते हैं। मैंने अलग-अलग सर्वरों पर संदेश भेजने के लिए Redis pub/sub का उपयोग किया।

सबसे कठिन हिस्से ये थे:

  • उपयोगकर्ताओं के अचानक डिस्कनेक्ट होने पर कनेक्शन को साफ (clean up) करना।
  • उन रूम्स में संदेश भेजने से रोकना जिन्हें उपयोगकर्ता छोड़ चुका है।
  • ghost sessions बनाए बिना रीकनेक्ट को संभालना।

मैंने सीखा कि साधारण flags का उपयोग करने की तुलना में एक औपचारिक state machine बेहतर होती है।

रेटिंग सिस्टम

रेटिंग बनाना तब तक मामूली लगता है जब तक आप उसे खुद न बना लें। मुझे यह सुनिश्चित करना पड़ा कि:

  • उपयोगकर्ता एक ही सत्र को दो बार रेट नहीं कर सकते।
  • प्रोफाइल व्यू के लिए रेटिंग्स जल्दी aggregate हो जाएं।
  • ऐप में डेटा सुसंगत (consistent) बना रहे।

डुप्लिकेट्स को रोकने के लिए मैंने session IDs पर unique constraints का उपयोग किया और परफॉरमेंस बचाने के लिए औसत (averages) को कैश (cache) कर लिया।

सीखे गए सबक

अगर मैं आज इसे फिर से बनाता हूँ, तो मैं तीन चीजें बदलूँगा:

  1. मैचिंग और चैट को अलग-अलग मॉड्यूल में विभाजित करना।
  2. WebSocket कनेक्शन स्टेट्स के लिए स्पष्ट मॉडलिंग का उपयोग करना।
  3. पहले दिन से ही चैट और मैचिंग के लिए बेहतर लॉग्स और मेट्रिक्स जोड़ना।

सॉफ्टवेयर बनाना छोटे-छोटे निर्णयों की एक श्रृंखला है। ये निर्णय तय करते हैं कि आपका सिस्टम साफ-सुथरा है या कमजोर (brittle)।

क्या आपने कभी लाइव चैट या मैचिंग सिस्टम बनाया है? आप क्या अलग करेंगे?

स्रोत: https://dev.to/jaeger974/simple-live-chat-almost-sank-this-release-2pn7