একটি সাধারণ লাইভ চ্যাট প্রায় এই রিলিজটিকে ডুবিয়ে দিচ্ছিল
একটি সাধারণ লাইভ চ্যাট সিস্টেম আমার সাম্প্রতিক রিলিজটিকে প্রায় ধ্বংস করে দিচ্ছিল।
শুনতে সহজ মনে হয়। আপনি কাছাকাছি থাকা ব্যবহারকারীদের দেখান এবং তাদের কথা বলতে দেন। কিন্তু প্রযুক্তিগত বাস্তবতা অনেক বেশি কঠিন। আমাকে লাইভ চ্যাটের সাথে জিওলোকেশন (geolocation) এবং একটি রেটিং সিস্টেম যুক্ত করতে হয়েছিল। এটি পর্দার আড়ালে ব্যাপক জটিলতা তৈরি করেছিল।
আর্কিটেকচার:
• ফ্রন্টএন্ড: React এবং TypeScript। • ব্যাকএন্ড: Express এবং WebSockets সহ Node.js। • ডাটাবেস: ব্যবহারকারী এবং রেটিংয়ের জন্য PostgreSQL। • ক্যাশ: সক্রিয় সেশন এবং প্রেজেন্সের (presence) জন্য Redis।
জিওলোকেশন সমস্যা
লোকেশন অনুযায়ী ব্যবহারকারীদের মেলানো সহজ নয়। আমাকে অনেকগুলো এজ কেস (edge cases) সামলাতে হয়েছে:
- অক্ষাংশ (latitude) এবং দ্রাঘিমাংশ (longitude) সংরক্ষণ করা।
- দূরত্ব অনুসন্ধানের জন্য Postgres এক্সটেনশন ব্যবহার করা।
- যারা লোকেশন পারমিশন দিতে অস্বীকার করে তাদের হ্যান্ডেল করা।
- অ্যাপ না খুলেই ব্যবহারকারী সরে গেলে স্টেল (stale) ডেটা ম্যানেজ করা।
আমি যদি এটি আবার করতাম, তবে লোকেশন সংগ্রহ এবং ম্যাচিং প্রক্রিয়াকে আলাদা আলাদা সার্ভিসে ভাগ করে দিতাম।
লাইভ চ্যাটের বাস্তবতা
WebSockets রিয়েল-টাইম ফিচার নিয়ে আসে, কিন্তু এটি বিশৃঙ্খলাও নিয়ে আসে। বিভিন্ন সার্ভারের মধ্যে মেসেজ পাঠানোর জন্য আমি Redis pub/sub ব্যবহার করেছি।
সবচেয়ে কঠিন অংশগুলো ছিল:
- ব্যবহারকারীরা অপ্রত্যাশিতভাবে ডিসকানেক্ট হয়ে গেলে কানেকশনগুলো ক্লিন আপ করা।
- ব্যবহারকারী যে রুম ছেড়ে চলে গেছেন সেখানে মেসেজ পাঠানো রোধ করা।
- ঘোস্ট সেশন (ghost sessions) তৈরি না করে রিকানেক্ট হ্যান্ডেল করা।
আমি শিখেছি যে সাধারণ ফ্ল্যাগ (flags) ব্যবহারের চেয়ে একটি ফরমাল স্টেট মেশিন (state machine) ব্যবহার করা অনেক ভালো।
রেটিং সিস্টেম
রেটিং সিস্টেম তৈরি করার আগ পর্যন্ত এটি খুব তুচ্ছ মনে হয়। আমাকে নিশ্চিত করতে হয়েছিল যে:
- ব্যবহারকারীরা একই সেশনে দুবার রেটিং দিতে পারবে না।
- প্রোফাইল ভিউয়ের জন্য রেটিংগুলো দ্রুত অ্যাগ্রিগেট (aggregate) হবে।
- অ্যাপের সর্বত্র ডেটা সামঞ্জস্যপূর্ণ থাকবে।
ডুপ্লিকেট রোধ করতে আমি সেশন আইডি-তে ইউনিক কনস্ট্রেইন্ট (unique constraints) ব্যবহার করেছি এবং পারফরম্যান্স বাড়াতে গড় রেটিংগুলো ক্যাশ (cache) করে রেখেছি।
শিক্ষণীয় বিষয়সমূহ
আমি যদি আজ এটি আবার তৈরি করি, তবে আমি তিনটি জিনিস পরিবর্তন করব:
১. ম্যাচিং এবং চ্যাটকে আলাদা মডিউলে ভাগ করব। ২. WebSocket কানেকশন স্টেটের জন্য স্পষ্ট মডেলিং ব্যবহার করব। ৩. প্রথম দিন থেকেই চ্যাট এবং ম্যাচিংয়ের জন্য আরও উন্নত লগ এবং মেট্রিক্স যোগ করব।
সফটওয়্যার তৈরি করা হলো ছোট ছোট সিদ্ধান্তের একটি ধারাবাহিকতা। এই সিদ্ধান্তগুলোই নির্ধারণ করে আপনার সিস্টেমটি পরিচ্ছন্ন নাকি ভঙ্গুর হবে।
আপনি কি কখনও কোনো লাইভ চ্যাট বা ম্যাচিং সিস্টেম তৈরি করেছেন? আপনি ভিন্নভাবে কী করতেন?
উৎস: https://dev.to/jaeger974/simple-live-chat-almost-sank-this-release-2pn7