রিয়েল এস্টেট অপারেশনস প্ল্যাটফর্ম

ক্লায়েন্টের ব্যবসা পরিচালনার জন্য ব্যবহৃত সিস্টেমটি ছিল ASP1 দিয়ে তৈরি একটি পুরোনো অ্যাপ্লিকেশন, যা চলত Windows-ভিত্তিক একটি ভার্চুয়াল সার্ভারে। সিস্টেমটি কীভাবে তৈরি করা হয়েছিল, ডেটাবেস কোথায় ছিল কিংবা অ্যাপ্লিকেশনের ভেতরের কাজগুলো কীভাবে পরিচালিত হতো, এসব বিষয়ে পরিষ্কার কোনো ডকুমেন্টেশন ছিল না। ক্লায়েন্টের কাছে ছিল শুধু ভার্চুয়াল সার্ভারের অ্যাক্সেস।

প্রতিদিনের কাজ করতে গিয়ে ক্লায়েন্টকে নানা সমস্যায় পড়তে হতো। অ্যাপ্লিকেশন হঠাৎ হ্যাং হয়ে যেত, আর এমন হলে সার্ভার বা অ্যাপ্লিকেশন রিস্টার্ট করা ছাড়া কার্যকর কোনো সমাধান থাকত না। বেশিরভাগ ফিল্টার ঠিকমতো কাজ করত না। যেগুলো কাজ করত, সেগুলোও ফলাফল দেখাতে অস্বাভাবিক রকম সময় নিত।

কিছু পেজ লোড হতে এক মিনিটেরও বেশি সময় লাগত। আবার ডেটাবেস টাইমআউটের কারণে কিছু পেজ লোডই হতো না।

সময়ের সঙ্গে সিস্টেমটির UI-ও ব্যবহারকারীদের জন্য বেশ অসুবিধাজনক হয়ে উঠেছিল। সব মিলিয়ে, ব্যবসার গুরুত্বপূর্ণ কাজের জন্য নির্ভরশীল এই অ্যাপ্লিকেশনটি ব্যবহার করাই কঠিন হয়ে পড়েছিল। স্বাভাবিকভাবেই, ক্লায়েন্টকে তাঁদের গ্রাহকদের কাছ থেকে নিয়মিত অভিযোগ শুনতে হতো।

শুধু নতুন একটি UI তৈরি করলেই সমস্যার সমাধান হতো না। পুরোনো সিস্টেমের কার্যকারিতা বজায় রেখে ডেটা, পারফরম্যান্স ও নিরাপত্তার বিষয়গুলোও নতুন করে নিশ্চিত করতে হতো।

সবচেয়ে বড় চ্যালেঞ্জ ছিল ডেটাবেস। সেখানে ৫০ মিলিয়নেরও বেশি রেকর্ড ছিল, এবং মাইগ্রেশনের সময় কোনো ডেটা হারানো বা পরিবর্তন হওয়া চলবে না। পুরোনো সিস্টেমের প্রতিটি রেকর্ড অক্ষত রেখে নতুন প্ল্যাটফর্মে নিয়ে যেতে হতো।

এর পাশাপাশি, ক্লায়েন্ট প্রতিদিন .xlsx ফাইলের মাধ্যমে বিপুল পরিমাণ নতুন ডেটা আপলোড করতেন। এসব ফাইলের ডেটা সঠিক ফরম্যাটে আছে কি না, তা যাচাই করার ব্যবস্থা থাকা জরুরি ছিল। ভুল ডেটা যেন সিস্টেমে ঢুকে না পড়ে, সেটিও নিশ্চিত করতে হতো।

ক্লায়েন্ট পুরো ইনফ্রাস্ট্রাকচার AWS-এ রাখতে চেয়েছিলেন। অ্যাপ্লিকেশন ও ইনফ্রাস্ট্রাকচারের নিরাপত্তা ছিল তাঁদের অন্যতম প্রধান অগ্রাধিকার। তবে নিরাপত্তা ও পারফরম্যান্স নিশ্চিত করতে গিয়ে AWS-এর খরচও যুক্তিসংগত পর্যায়ে রাখতে হতো।

সবশেষে ছিল সময়সীমা। পুরোনো অ্যাপ্লিকেশনটি প্রায় ব্যবহার-অনুপযোগী হয়ে পড়েছিল, তাই ক্লায়েন্ট যত দ্রুত সম্ভব নতুন সিস্টেম চালু করতে চেয়েছিলেন।

১. প্রথম কাজ ছিল ডেটাবেসের ব্যাকআপ নেওয়া

পুরো প্রজেক্টে সবচেয়ে কঠিন কাজগুলোর একটি ছিল পুরোনো ডেটাবেসের ব্যাকআপ নেওয়া। আমার কাছে ডেটাবেসে সরাসরি অ্যাক্সেস ছিল না; অ্যাডমিন অ্যাক্সেস ছিল শুধু ভার্চুয়াল মেশিনে।

এই পরিস্থিতিতে ভার্চুয়াল মেশিনের অ্যাক্সেস ব্যবহার করে কীভাবে ডেটাবেসের ব্যাকআপ নেওয়া যায়, তা নিয়ে বিস্তারিত গবেষণা করতে হয়েছে। শেষ পর্যন্ত একটি পদ্ধতি খুঁজে পাই, যদিও সেটি কিছুটা ঝুঁকিপূর্ণ ছিল। পদ্ধতিটি সফলভাবে কাজ করে এবং আমি ডেটাবেসের ব্যাকআপ নিতে সক্ষম হই।

এটি গুরুত্বপূর্ণ ছিল, কারণ ডেটাবেসের ব্যাকআপ নিশ্চিত না করে এত বড় একটি সিস্টেম পুনর্নির্মাণের কাজে এগোনোই ঝুঁকিপূর্ণ হতো।

২. সোর্স কোড ছাড়াই পুরোনো অ্যাপ্লিকেশন পুনর্নির্মাণ

পুরোনো ASP1 অ্যাপ্লিকেশনের সোর্স কোড আমার হাতে ছিল না। ফলে কোড দেখে এর ফিচারগুলো বুঝে নেওয়ার সুযোগ ছিল না। বরং পুরোনো প্ল্যাটফর্মটি ব্যবহার করে, বিভিন্ন ফিচার পরীক্ষা করে এবং তার আচরণ পর্যবেক্ষণ করে পুরো সিস্টেমটি বুঝতে হয়েছে।

এরপর সেই অভিজ্ঞতার ভিত্তিতে নতুন অ্যাপ্লিকেশনে ফিচারগুলো একে একে তৈরি করেছি।

এই প্রক্রিয়ায় ক্লায়েন্টের সহযোগিতা ছিল অসাধারণ। পুরোনো সিস্টেমের কার্যকারিতা বুঝতে এবং প্রত্যাশিত আচরণ নিশ্চিত করতে তাঁদের কাছ থেকে প্রয়োজনীয় সহায়তা পেয়েছি। আমার কাজের অভিজ্ঞতায় সহযোগিতার দিক থেকে তাঁরা অন্যতম সেরা ক্লায়েন্ট ছিলেন।

৩. প্রজেক্টের জন্য উপযুক্ত টেক স্ট্যাক নির্বাচন

ক্লায়েন্টের প্রয়োজন ছিল একটি দ্রুত, নির্ভরযোগ্য এবং নিরাপদ সিস্টেম, যা AWS-এ চলবে এবং নির্দিষ্ট সময়ের মধ্যে তৈরি করতে হবে। তাই প্রযুক্তি নির্বাচনের ক্ষেত্রে পরিচিত টুলের পাশাপাশি পারফরম্যান্স ও বাস্তব সীমাবদ্ধতাগুলোও বিবেচনায় নিয়েছি।

ফ্রন্টএন্ডের জন্য React বেছে নিই। নির্ধারিত সময়ের মধ্যে জটিল UI তৈরি করার ক্ষেত্রে React আমার পরিচিত একটি প্রযুক্তি ছিল। Vite দিয়ে ফ্রন্টএন্ড সেটআপ করেছি এবং UI তৈরিতে ব্যবহার করেছি shadcn।

ব্যাকএন্ডের জন্য বেছে নিয়েছি NestJS। অ্যাপ্লিকেশনটির নির্ভরযোগ্যতা বজায় রাখা এবং সীমিত সময়ের মধ্যে ডেভেলপমেন্ট শেষ করার জন্য এটি আমার কাছে ভালো পছন্দ ছিল। NestJS-এর ডিফল্ট Express অ্যাডাপ্টারের পরিবর্তে Fastify ব্যবহার করেছি, কারণ এটি হালকা এবং উচ্চ রিকোয়েস্ট ভলিউম সামলানোর জন্য উপযুক্ত।

ডেটাবেসের জন্য AWS Aurora ও AWS RDS-এর বিকল্পগুলো বিবেচনা করেছি। প্রজেক্টের চাহিদা অনুযায়ী ধারাবাহিক পারফরম্যান্স পাওয়া এখানে গুরুত্বপূর্ণ ছিল। অটো-স্কেলিংয়ের ওপর নির্ভর করে পারফরম্যান্সের সমস্যা সামলানোর ঝুঁকি নিতে চাইনি। সবকিছু বিবেচনা করে AWS RDS বেছে নিই।

৪. AWS-এ ডেপ্লয়মেন্ট ও নিরাপত্তা নিশ্চিত করা

ব্যাকএন্ড ডেপ্লয়মেন্টের জন্য AWS Elastic Beanstalk ব্যবহার করেছি। এর মাধ্যমে Node.js অ্যাপ্লিকেশন ডেপ্লয় করা এবং প্রয়োজন অনুযায়ী horizontal ও vertical scaling পরিচালনা করা সহজ হয়েছে। ব্যাকএন্ডের জন্য লোড ব্যালান্সিংসহ দুটি ইনস্ট্যান্স ব্যবহার করেছি।

নিরাপত্তার জন্য শুরু থেকেই একাধিক স্তরে ব্যবস্থা নিতে হয়েছে। Authentication-এর জন্য ব্যবহার করেছি AWS Cognito। এর পাশাপাশি Cognito-ভিত্তিক roles ও permissions দিয়ে authorization পরিচালনা করেছি, যাতে ব্যবহারকারীরা তাঁদের অনুমতি অনুযায়ী সিস্টেম ব্যবহার করতে পারেন।

ফ্রন্টএন্ড কনটেন্ট সরবরাহের জন্য ব্যবহার করেছি AWS CloudFront। আবার API-তে অতিরিক্ত রিকোয়েস্টের চাপ নিয়ন্ত্রণ করতে rate limiting-এর ব্যবস্থা করেছি, যার জন্য AWS ElastiCache for Redis ব্যবহার করেছি।

এই প্রজেক্টে নিরাপত্তাকে শুধু ডেপ্লয়মেন্টের সময় বিবেচনা করিনি; বরং ব্যবহারকারীর অ্যাক্সেস থেকে শুরু করে API-র রিকোয়েস্ট নিয়ন্ত্রণ পর্যন্ত পুরো সিস্টেমের অংশ হিসেবেই দেখেছি।

৫. একাধিক ধরনের ব্যবহারকারীর জন্য অ্যাক্সেস নিয়ন্ত্রণ

সিস্টেমটিতে পাঁচটিরও বেশি ধরনের ব্যবহারকারী ছিলেন। প্রত্যেকের ভূমিকা, অনুমতি এবং সাবস্ক্রিপশন অনুযায়ী ডেটা দেখার অধিকার আলাদা ছিল।

এ কারণে সব ব্যবহারকারীর জন্য একই API response সরবরাহ করা সম্ভব ছিল না। কোন ব্যবহারকারী কোন তথ্য দেখতে পারবেন, তা নির্ধারণ করতে হয়েছে তাঁদের role ও subscription অনুযায়ী।

এই নিয়মগুলো API-তে সতর্কতার সঙ্গে বাস্তবায়ন করেছি, যেন প্রতিটি ব্যবহারকারী শুধু তাঁর অনুমোদিত ডেটাতেই অ্যাক্সেস পান। এতগুলো ব্যবহারকারীর ধরন ও ভিন্ন ভিন্ন অনুমতি সামলানোর ক্ষেত্রে role-based access control ছিল সিস্টেমটির অন্যতম গুরুত্বপূর্ণ অংশ।

৬. ৫০ মিলিয়নেরও বেশি রেকর্ড নিয়ে পারফরম্যান্স অপটিমাইজেশন

ডেটাবেসে এত বিপুল পরিমাণ রেকর্ড থাকায় শুধু নতুন অ্যাপ্লিকেশন তৈরি করলেই চলত না। সার্চ, ফিল্টার এবং অন্যান্য গুরুত্বপূর্ণ অপারেশন দ্রুত সম্পন্ন করাও জরুরি ছিল। পিক আওয়ারে সিস্টেমটিকে প্রতি মিনিটে ৩০ হাজারেরও বেশি রিকোয়েস্ট সামলানোর উপযোগী করতে হয়েছে।

এ জন্য প্রথমেই গুরুত্বপূর্ণ query-গুলো নিয়ে কাজ করেছি। একই query-র বিভিন্ন সংস্করণ তৈরি করে চালিয়েছি এবং প্রতিটির execution time পরিমাপ করেছি। পরীক্ষার ফলাফলের ভিত্তিতে সবচেয়ে ভালো পারফরম্যান্স দেওয়া সংস্করণটি বেছে নিয়েছি।

ডেটাবেসে সার্চ ও ফিল্টারের ধরন অনুযায়ী প্রয়োজনীয় index তৈরি করেছি। সাধারণ ফিল্ডের জন্য B-tree index এবং উপযুক্ত ক্ষেত্রে GIN index ব্যবহার করেছি। Full-text search-এর জন্য tsvector-ভিত্তিক ব্যবস্থাও যুক্ত করেছি।

এর পাশাপাশি, যেসব query বারবার চালানো হতো, সেগুলোর ফলাফল নির্দিষ্ট সময়ের জন্য cache করার ব্যবস্থা করেছি। Cache-এর মেয়াদ ঠিক করার সময় ডেটার ধরন ও ব্যবহারের প্রয়োজন বিবেচনায় নিয়েছি।

এই কাজগুলোর সম্মিলিত ফল ছিল উল্লেখযোগ্য। আগে যেসব query শেষ হতে ৬০ সেকেন্ডেরও বেশি সময় লাগত, সেগুলোর পারফরম্যান্স নাটকীয়ভাবে উন্নত হয়েছে। নতুন সিস্টেমে অধিকাংশ query এখন ২০০–২৫০ মিলিসেকেন্ডের নিচে সম্পন্ন হয়।

৭. ডেটা আপলোডে ভুল ও ডুপ্লিকেট ঠেকানো

ক্লায়েন্টের ডেটা প্রোভাইডাররা .xlsx ও .csv ফাইলের মাধ্যমে নিয়মিত নতুন রেকর্ড আপলোড করতেন। কিন্তু সব ফাইলের ডেটা প্রত্যাশিত ফরম্যাটে থাকত না। তাই শুধু ফাইল থেকে ডেটা পড়ে ডেটাবেসে যুক্ত করলেই হতো না; আপলোড করা ডেটা সঠিক কি না, তা কঠোরভাবে যাচাই করার ব্যবস্থা তৈরি করেছি।

ফাইলের ফরম্যাট ভুল হলে আপলোডের সময়ই যেন প্রোভাইডার বুঝতে পারেন কী সমস্যা হয়েছে, সে জন্য তাৎক্ষণিক feedback দেওয়ার ব্যবস্থা করেছি। এতে ভুল ডেটা শনাক্ত করার জন্য পরবর্তী সময় পর্যন্ত অপেক্ষা করতে হয় না।

আরেকটি বড় সমস্যা ছিল ডুপ্লিকেট ডেটা। এত বড় ডেটাবেসে আগে থেকে থাকা রেকর্ডের সঙ্গে নতুন ডেটা মিলিয়ে ডুপ্লিকেট শনাক্ত করা সহজ কাজ নয়। এ জন্য একটি duplicate detection ব্যবস্থা তৈরি করেছি, যা নতুন ডেটা আপলোডের সময় ডুপ্লিকেট শনাক্ত করতে পারে। ডুপ্লিকেট পাওয়া গেলে অ্যাডমিন ও সংশ্লিষ্ট প্রোভাইডার—দুজনকেই জানানোর ব্যবস্থা করেছি।

৫০ মিলিয়নেরও বেশি রেকর্ডের মধ্যে ডুপ্লিকেট খোঁজার প্রক্রিয়াটি দ্রুত সম্পন্ন করাও এখানে গুরুত্বপূর্ণ ছিল। তাই শুধু সঠিক ফলাফল পাওয়াই নয়, এই যাচাইয়ের পারফরম্যান্সও অপটিমাইজ করেছি।

৮. আপলোড করা ফাইলের স্বয়ংক্রিয় ব্যাকআপ

আগে ক্লায়েন্টকে ডেটা প্রোভাইডারদের আপলোড করা ফাইলগুলো আলাদাভাবে সংরক্ষণ করতে হতো, যাতে প্রয়োজনে সেগুলো ব্যাকআপ হিসেবে ব্যবহার করা যায়।

নতুন সিস্টেমে ফাইলগুলো AWS S3-এ সংরক্ষণ করার ব্যবস্থা করেছি। ফলে ক্লায়েন্টকে আর প্রতিটি ফাইল ম্যানুয়ালি ব্যাকআপ হিসেবে রাখতে হয় না। প্রয়োজন হলে তাঁরা যেকোনো সময় সংরক্ষিত ফাইল ডাউনলোড করতে পারেন।

এতে ফাইল সংরক্ষণের কাজ সহজ হওয়ার পাশাপাশি পুরোনো আপলোড করা ডেটার ফাইলগুলোতে পরে ফিরে যাওয়ার সুবিধাও রয়েছে।

নতুন সিস্টেমটি এক বছরেরও বেশি সময় ধরে প্রোডাকশনে চলছে এবং নির্ভরযোগ্যভাবে কাজ করছে।

সবচেয়ে বড় পরিবর্তন এসেছে পারফরম্যান্সে। আগে কিছু পেজ লোড হতে ৬০ সেকেন্ডেরও বেশি সময় লাগত। কিছু পেজ আবার ডেটাবেস টাইমআউটের কারণে ঠিকমতো কাজ করত না। নতুন সিস্টেমে সেই পেজগুলোর লোডিং টাইম কমে প্রায় ২০০–২৫০ মিলিসেকেন্ডে এসেছে।

শুধু পেজ লোডের সময় কমানোই নয়, নতুন প্ল্যাটফর্মটি ৫০ মিলিয়নেরও বেশি রেকর্ড নিয়ে কাজ করতে পারে এবং পিক আওয়ারে প্রতি মিনিটে ৩০ হাজারেরও বেশি রিকোয়েস্ট সামলাতে সক্ষম হয়েছে।

ডেটা আপলোডের প্রক্রিয়াটিও আগের চেয়ে অনেক বেশি নিয়ন্ত্রিত। ভুল ফরম্যাটের ডেটা শনাক্ত করার পাশাপাশি ডুপ্লিকেট রেকর্ড যুক্ত হওয়া ঠেকানোর ব্যবস্থা রয়েছে। বর্তমানে ডেটা প্রোভাইডাররা প্রতিদিন প্রায় ৫ হাজার রেকর্ড আপলোড করেন, যদিও কোনো কোনো দিন সংখ্যাটি কিছুটা কম থাকে।

ক্লায়েন্ট নতুন ডিজাইন এবং পারফরম্যান্সের উন্নতি নিয়ে সন্তুষ্ট ছিলেন। তাঁদের আগের প্রায় ব্যবহার-অনুপযোগী অ্যাপ্লিকেশনটির পরিবর্তে এখন রয়েছে একটি আধুনিক সিস্টেম, যা এক বছরেরও বেশি সময় ধরে প্রোডাকশনে নির্ভরযোগ্যভাবে চলছে।

আমার কাছে এই প্রজেক্টের সবচেয়ে উল্লেখযোগ্য দিক ছিল শুধু পুরোনো প্রযুক্তি বদলে ফেলা নয়, বরং সীমিত অ্যাক্সেস, ডকুমেন্টেশনের অভাব এবং বিপুল পরিমাণ পুরোনো ডেটার মতো বাধা পেরিয়ে পুরো সিস্টেমটিকে ব্যবহারযোগ্য ও নির্ভরযোগ্য করে তোলা।