𝗦𝗶𝗺𝗽𝗹𝗲 𝗟𝗶𝘃𝗲 𝗖𝗵𝗮𝘁 𝗔𝗹𝗺𝗼𝘀𝘁 𝗦𝗮𝗻𝗸 𝗧𝗵𝗶𝘀 𝗥𝗲𝗹𝗲𝗮𝘀𝗲

ఒక సాధారణ లైవ్ చాట్ సిస్టమ్ నా తాజా రిలీజ్‌ను దాదాపు నాశనం చేసింది.

ఇది వినడానికి సులభంగా అనిపించవచ్చు. దగ్గరలో ఉన్న వినియోగదారులను చూపించి, వారిని మాట్లాడుకోనివ్వడం. కానీ సాంకేతిక వాస్తవం చాలా కష్టమైనది. నేను లైవ్ చాట్‌ను జియోలొకేషన్ (geolocation) మరియు రేటింగ్ సిస్టమ్‌తో అనుసంధానించాల్సి వచ్చింది. ఇది లోపల (under the hood) భారీ సంక్లిష్టతను సృష్టించింది.

ఆర్కిటెక్చర్ (The Architecture):

• Frontend: React మరియు TypeScript. • Backend: Node.js తో Express మరియు WebSockets. • Database: వినియోగదారులు మరియు రేటింగ్‌ల కోసం PostgreSQL. • Cache: యాక్టివ్ సెషన్లు మరియు ప్రెజెన్స్ (presence) కోసం Redis.

జియోలొకేషన్ సమస్య (The Geolocation Problem)

లొకేషన్ ఆధారంగా వినియోగదారులను మ్యాచ్ చేయడం అంత సులభం కాదు. నేను అనేక ఎడ్జ్ కేస్‌లను (edge cases) ఎదుర్కోవాల్సి వచ్చింది:

  • లాటిట్యూడ్ (latitude) మరియు లాంగిట్యూడ్ (longitude) ని స్టోర్ చేయడం.
  • దూరాన్ని కనుగొనడానికి (query distance) Postgres ఎక్స్‌టెన్షన్‌లను ఉపయోగించడం.
  • లొకేషన్ పర్మిషన్లను నిరాకరించే వినియోగదారులను హ్యాండిల్ చేయడం.
  • యాప్‌ను ఓపెన్ చేయకుండానే వినియోగదారుడు కదిలినప్పుడు పాత డేటాను (stale data) నిర్వహించడం.

నేను మళ్ళీ ఇలా చేయాల్సి వస్తే, లొకేషన్ సేకరణను మరియు మ్యాచింగ్‌ను వేర్వేరు సర్వీసులుగా విడదీస్తాను.

లైవ్ చాట్ వాస్తవం (The Live Chat Reality)

WebSockets రియల్-టైమ్ ఫీచర్లను అందిస్తాయి, కానీ అవి గందరగోళాన్ని కూడా తెస్తాయి. వేర్వేరు సర్వర్‌ల మధ్య సందేశాలను పంపడానికి నేను Redis pub/subని ఉపయోగించాను.

కష్టమైన భాగాలు ఇవి:

  • వినియోగదారులు అకస్మాత్తుగా డిస్‌కనెక్ట్ అయినప్పుడు కనెక్షన్‌లను క్లీన్ చేయడం.
  • వినియోగదారుడు వదిలివేసిన రూమ్‌లకు సందేశాలు వెళ్లకుండా చూడటం.
  • గోస్ట్ సెషన్లను (ghost sessions) సృష్టించకుండా రీకనెక్ట్‌లను హ్యాండిల్ చేయడం.

సాధారణ ఫ్లాగ్‌లను ఉపయోగించడం కంటే ఫార్మల్ స్టేట్ మెషీన్ (formal state machine) వాడటం ఉత్తమమని నేను తెలుసుకున్నాను.

రేటింగ్ సిస్టమ్ (The Rating System)

రేటింగ్‌లు నిర్మించే వరకు చాలా చిన్నవిగా అనిపిస్తాయి. నేను వీటిని నిర్ధారించాల్సి వచ్చింది:

  • వినియోగదారులు ఒకే సెషన్‌కు రెండుసార్లు రేటింగ్ ఇవ్వకూడదు.
  • ప్రొఫైల్ వ్యూస్ కోసం రేటింగ్‌లు త్వరగా అగ్రిగేట్ (aggregate) అవ్వాలి.
  • యాప్ అంతటా డేటా స్థిరంగా (consistent) ఉండాలి.

డూప్లికేట్‌లను నివారించడానికి నేను సెషన్ ఐడిలపై (session IDs) యూనిక్ కన్‌స్ట్రెయింట్‌లను (unique constraints) ఉపయోగించాను మరియు పనితీరును మెరుగుపరచడానికి సగటులను (averages) క్యాష్ (cache) చేశాను.

నేర్చుకున్న పాఠాలు (Lessons Learned)

నేను ఈ రోజు దీనిని మళ్ళీ నిర్మిస్తే, మూడు విషయాలను మారుస్తాను:

  1. మ్యాచింగ్ మరియు చాట్‌ను వేర్వేరు మాడ్యూల్స్‌గా విడదీయడం.
  2. WebSocket కనెక్షన్ స్టేట్‌ల కోసం స్పష్టమైన మోడలింగ్‌ను ఉపయోగించడం.
  3. మొదటి రోజు నుండే చాట్ మరియు మ్యాచింగ్ కోసం మెరుగైన లాగ్‌లు (logs) మరియు మెట్రిక్స్‌ను జోడించడం.

సాఫ్ట్‌వేర్ నిర్మించడం అనేది చిన్న చిన్న నిర్ణయాల శ్రేణి. మీ సిస్టమ్ క్లీన్‌గా ఉంటుందా లేదా బలహీనంగా (brittle) ఉంటుందా అనేది ఈ నిర్ణయాలే నిర్ణయిస్తాయి.

మీరు ఎప్పుడైనా లైవ్ చాట్ లేదా మ్యాచింగ్ సిస్టమ్‌ను నిర్మించారా? మీరు వేరే విధంగా ఏమి చేసేవారు?

మూలం: https://dev.to/jaeger974/simple-live-chat-almost-sank-this-release-2pn7