A
Loading
Loading
দশজন ব্যবহারকারীর জন্য একটা অ্যাপ বানানো সহজ। কিন্তু সেই একই অ্যাপ যখন দশ লাখ ব্যবহারকারী একসঙ্গে ব্যবহার করতে শুরু করে — সার্ভার ধীর হয়ে যায়, ডেটাবেস হাঁপাতে থাকে, পেজ লোড হতে সেকেন্ড গড়িয়ে মিনিট হয় — তখনই বোঝা যায় আসল ইঞ্জিনিয়ারিংটা কোথায়।
ভালো খবর হলো, MERN Stack ঠিকভাবে তৈরি করলে একই কোডবেস MVP থেকে শুরু করে কোটি ব্যবহারকারী পর্যন্ত স্কেল করতে পারে — পুরো রিরাইট ছাড়াই। কিন্তু এই "ঠিকভাবে" শব্দটাই আসল রহস্য, যা ৯০% ডেভেলপার শুরুতে মিস করে।
এই গাইডে আমরা ধাপে ধাপে দেখব — ২০২৬ সালের আধুনিক MERN Stack আসলে কেমন, একটা স্কেলেবল আর্কিটেকচার কীভাবে সাজাতে হয়, ব্যাকএন্ড আর ডেটাবেস কীভাবে স্কেল করতে হয়, আর কোন ভুলগুলো এড়িয়ে চললে আপনার অ্যাপ লোডের চাপে ভেঙে পড়বে না। সঙ্গে থাকবে বাস্তব কোড উদাহরণ।
হ্যাঁ, পুরোপুরি। MERN-এর সবচেয়ে বড় শক্তি হলো এর আর্কিটেকচার এমনভাবে বিবর্তিত করা যায় যে দশ-ব্যবহারকারীর MVP থেকে শুরু করে লক্ষ-কোটি ব্যবহারকারীর সিস্টেমে রূপ নিতে পারে — মূল কাঠামো না ভেঙেই।
এটা শুধু তত্ত্ব নয়: LinkedIn, Netflix আর Uber-এর মতো প্রতিষ্ঠান তাদের অবকাঠামোর গুরুত্বপূর্ণ অংশ Node.js-এর ওপর গড়ে তুলেছে। একটাই ভাষা (JavaScript) পুরো স্ট্যাক জুড়ে চলায় ডেভেলপমেন্ট দ্রুত হয়, আর Node.js-এর non-blocking, ইভেন্ট-ড্রিভেন মডেল হাজার হাজার সমসাময়িক রিকোয়েস্ট সামলাতে পারে।
তবে একটা সতর্কবার্তা: MERN নিজে থেকে স্কেলেবল নয় — আপনি কীভাবে বানাচ্ছেন তার ওপর নির্ভর করে। নিচের কৌশলগুলোই সেই পার্থক্য তৈরি করে।
মূল চারটি উপাদান এক থাকলেও, ২০২৬ সালের প্রোডাকশন MERN পাঁচ বছর আগের চেয়ে অনেক আলাদা:
MongoDB — নমনীয়, JSON-এর মতো ডকুমেন্ট-ভিত্তিক NoSQL ডেটাবেস (এখন বেশিরভাগ ক্ষেত্রে ম্যানেজড MongoDB Atlas ও Mongoose 8 সহ)।
Express.js 5 — হালকা ব্যাকএন্ড ফ্রেমওয়ার্ক, রাউটিং ও API তৈরির জন্য।
React 19.2 — ইন্টারঅ্যাকটিভ UI তৈরির লাইব্রেরি (Server Components, Actions-সহ নতুন ফিচার)।
Node.js 24 (LTS) — সার্ভার-সাইড JavaScript রানটাইম।
আর আধুনিক প্রোডাকশন স্ট্যাকে যুক্ত হয়েছে নতুন স্তর:
TypeScript পুরো কোডবেস জুড়ে — টাইপ-সেফটি ও কম বাগ।
Vite — দ্রুত বিল্ড ও ডেভ সার্ভার।
Next.js (ফ্রন্টএন্ডে) — SSR, SSG ও API রুট, যা SEO ও লোডিং স্পিড দেয়।
TanStack Query — স্মার্ট ডেটা ফেচিং ও ক্যাশিং।
Docker + Kubernetes — কনটেইনারাইজেশন ও স্কেলিং।
CI/CD পাইপলাইন — স্বয়ংক্রিয় টেস্ট ও ডিপ্লয়মেন্ট।
নোট (ভার্সন): নতুন প্রোডাকশন প্রজেক্টে Node.js 24 ব্যবহার করুন — জুন ২০২৬ অনুযায়ী এটাই Active LTS, এতে npm 11, নতুন V8 ইঞ্জিন এবং বিল্ট-ইন TypeScript সাপোর্ট আছে। Node 22 এখনো সাপোর্টেড, তবে এপ্রিল ২০২৭-এ এর মেয়াদ শেষ হবে।
একটা স্কেলেবল অ্যাপ স্তরভিত্তিক (layered) আর্কিটেকচার অনুসরণ করে, যেখানে প্রতিটা স্তরের কাজ আলাদা:
ক্লায়েন্ট স্তর (Frontend): React/Next.js — ব্যবহারকারীর সঙ্গে যোগাযোগ।
API স্তর (Node.js): Express — রাউটিং, মিডলওয়্যার, ভ্যালিডেশন, অথেন্টিকেশন, বিজনেস লজিক।
মডেল স্তর (Mongoose): ডেটাবেস স্কিমা, ভ্যালিডেশন, ইনডেক্স, সম্পর্ক।
ডেটাবেস স্তর (MongoDB): আসল ডেটা সংরক্ষণ।
এই বিচ্ছিন্নতা (separation of concerns) থাকার ফলে যেকোনো একটা স্তর আলাদাভাবে স্কেল বা পরিবর্তন করা যায়। আধুনিক টিমগুলো একটা monorepo কাঠামো ব্যবহার করে, যেখানে ফ্রন্টএন্ড ও ব্যাকএন্ড আলাদা ফোল্ডারে থাকে কিন্তু শেয়ার্ড TypeScript টাইপ ব্যবহার করে:
my-app/
├── apps/
│ ├── web/ # React + Vite (অথবা Next.js)
│ └── api/ # Express + Node.js
├── packages/
│ └── shared/ # শেয়ার্ড TypeScript টাইপ ও ইউটিলিটি
├── docker-compose.yml
└── package.json
Node.js দ্রুত, কিন্তু ভুলভাবে লিখলে এটাই বটলনেক হয়ে যায়। মূল কৌশলগুলো:
১. ইভেন্ট লুপ ব্লক করবেন না। Node.js একটা single-threaded ইভেন্ট লুপে চলে। ভারী সিঙ্ক্রোনাস কাজ (যেমন বড় লুপ বা ক্রিপ্টো অপারেশন) দিয়ে এটা ব্লক করলে পুরো সার্ভার আটকে যায়। সবসময় async/await ব্যবহার করুন আর ভারী কাজ আলাদা worker বা message queue-তে পাঠান।
২. কানেকশন পুলিং ব্যবহার করুন। প্রতিটা রিকোয়েস্টে নতুন ডেটাবেস কানেকশন তৈরি না করে বিদ্যমান কানেকশন পুনর্ব্যবহার করুন — এতে লেটেন্সি কমে, স্কেলেবিলিটি বাড়ে:
import mongoose from "mongoose";
await mongoose.connect(process.env.MONGODB_URI, {
maxPoolSize: 50, // কানেকশন পুল — প্রতি রিকোয়েস্টে নতুন কানেকশন নয়
minPoolSize: 5,
serverSelectionTimeoutMS: 5000,
});
৩. হরাইজন্টাল স্কেলিং (সবচেয়ে গুরুত্বপূর্ণ)। একটা সার্ভারে বেশি RAM/CPU যোগ করার (vertical) বদলে একাধিক সার্ভারে অ্যাপের অনেকগুলো ইনস্ট্যান্স চালান, আর সামনে একটা লোড ব্যালেন্সার (NGINX) বসান যা ট্রাফিক ভাগ করে দেয়। Docker + Kubernetes এই কাজটা স্বয়ংক্রিয় করে — চাহিদা বাড়লে নতুন ইনস্ট্যান্স যোগ হয়, কমলে সরে যায়।
৪. Redis দিয়ে ক্যাশিং। বারবার চাওয়া হয় এমন ডেটা প্রতিবার ডেটাবেস থেকে না এনে Redis (ইন-মেমরি, মাইক্রোসেকেন্ডে সাড়া দেয়) থেকে দিন। এতে MongoDB-র ওপর চাপ অনেক কমে। ব্যবহারকারীর সেশন, কাউন্টার আর ঘনঘন পড়া ডেটার জন্য আদর্শ।
৫. রেট লিমিটিং ও মেসেজ কিউ। অপব্যবহার ঠেকাতে rate limiting, আর ইমেইল পাঠানো বা রিপোর্ট তৈরির মতো ভারী কাজ ব্যাকগ্রাউন্ডে চালাতে message queue (যেমন BullMQ/RabbitMQ) ব্যবহার করুন।
বেশিরভাগ স্কেলিং সমস্যার মূল আসলে ডেটাবেসে। এই কৌশলগুলো মাস্টার করুন:
১. ইনডেক্সিং — সবচেয়ে দ্রুত পারফরম্যান্স লাভ। যে ফিল্ডে ঘনঘন কোয়েরি হয়, সেখানে ইনডেক্স দিন। ইনডেক্স ছাড়া MongoDB পুরো কালেকশন স্ক্যান করে, যা ডেটা বাড়লে ভয়ানক ধীর হয়:
// বেশি-কোয়েরি হওয়া ফিল্ডে ইনডেক্স
userSchema.index({ email: 1 }, { unique: true });
userSchema.index({ createdAt: -1 });
// কম্পাউন্ড ইনডেক্স — একাধিক ফিল্ডে একসঙ্গে ফিল্টার করলে
orderSchema.index({ userId: 1, status: 1 });
সতর্কতা: প্রতিটা ফিল্ডে ইনডেক্স দেবেন না — প্রতিটা ইনডেক্স রাইট অপারেশনকে ধীর করে। শুধু যেখানে দরকার সেখানেই দিন।
২. স্মার্ট স্কিমা ডিজাইন। MongoDB-তে SQL-এর মতো join খরচসাপেক্ষ। তাই সম্পর্কিত ডেটা প্রায়ই আলাদা টেবিলের বদলে একসঙ্গে embed করুন। তবে ডকুমেন্ট অতিরিক্ত বড় বা গভীরভাবে নেস্টেড করবেন না।
৩. রেপ্লিকেশন (Replica Set)। ডেটার একাধিক কপি বিভিন্ন সার্ভারে রাখুন। এতে দুটো লাভ — পড়ার (read) লোড ভাগ হয়, আর একটা সার্ভার ফেল করলেও অ্যাপ চালু থাকে (high availability)।
৪. শার্ডিং (Sharding) — বড় স্কেলের জন্য। ডেটা যখন এক সার্ভারের ক্ষমতা ছাড়িয়ে যায়, তখন একটা shard key দিয়ে ডেটা একাধিক সার্ভারে ভাগ করুন। এটাই MongoDB-র হরাইজন্টাল স্কেলিংয়ের মূল ভিত্তি। তবে shard key বাছাই অত্যন্ত গুরুত্বপূর্ণ — ভুল key বাছলে কিছু shard-এ অতিরিক্ত চাপ পড়ে (hotspot) এবং স্কেলিংয়ের সুবিধা নষ্ট হয়।
৫. হট-পাথে ভারী aggregation এড়ান। জটিল aggregation pipeline শক্তিশালী কিন্তু খরচসাপেক্ষ। বেশি-ট্রাফিকের এন্ডপয়েন্টে এগুলো না চালিয়ে ফলাফল ক্যাশ করুন বা ব্যাকগ্রাউন্ড জবে precompute করে রাখুন।
শর্টকাট: নিজে শার্ডিং/রেপ্লিকেশন ম্যানেজ করতে না চাইলে MongoDB Atlas ব্যবহার করুন — এটা auto-scaling সহ এই জটিলতাগুলো নিজে সামলায়।
স্কেলেবিলিটি শুধু সার্ভারের ব্যাপার নয় — ব্যবহারকারী যেন দ্রুত পেজ পায়, সেটাও জরুরি:
Next.js ব্যবহার করুন যদি SEO গুরুত্বপূর্ণ হয়। এটি server-side rendering (SSR) ও static site generation (SSG) দেয়, যা সাধারণ React (যা ব্রাউজারে রেন্ডার হয়) এর তুলনায় অনেক ভালো SEO ও দ্রুত প্রথম লোড নিশ্চিত করে।
Code splitting ও lazy loading — পুরো অ্যাপ একবারে লোড না করে, যা দরকার তখন লোড করুন।
TanStack Query — সার্ভার ডেটা স্মার্টভাবে ক্যাশ ও সিঙ্ক করে, অপ্রয়োজনীয় রিকোয়েস্ট কমায়।
ছবি অপটিমাইজেশন ও bundle size নিয়ন্ত্রণে রাখুন।
একটা অ্যাপ "চলে" আর "প্রোডাকশন-রেডি" — এর মধ্যে বিরাট পার্থক্য:
TypeScript সর্বত্র — রানটাইম বাগ অনেকটাই কম্পাইল টাইমেই ধরা পড়ে।
Docker দিয়ে কনটেইনারাইজ করুন — যেকোনো পরিবেশে একই আচরণ:
# Node 24 — ২০২৬-এর Active LTS
FROM node:24-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 5000
CMD ["node", "dist/server.js"]
CI/CD পাইপলাইন (GitHub Actions ইত্যাদি) — প্রতিবার কোড পুশে স্বয়ংক্রিয় টেস্ট ও ডিপ্লয়মেন্ট।
মনিটরিং ও লগিং — সমস্যা ব্যবহারকারীর আগে আপনি যেন জানেন (যেমন Sentry, Grafana)।
এনভায়রনমেন্ট ম্যানেজমেন্ট — সিক্রেট কখনো কোডে হার্ডকোড নয়, .env-এ রাখুন।
স্কেল করার আগে নিরাপত্তা নিশ্চিত করুন — না হলে যত বড় হবে, ঝুঁকি তত বাড়বে:
অথেন্টিকেশন: JWT বা session-ভিত্তিক, পাসওয়ার্ড হ্যাশিং (bcrypt/argon2)।
ইনপুট ভ্যালিডেশন: প্রতিটা ইনপুট যাচাই করুন (Zod/Joi), NoSQL ইনজেকশন ঠেকাতে।
নিরাপত্তা হেডার: Helmet মিডলওয়্যার ব্যবহার করুন।
রেট লিমিটিং ও HTTPS বাধ্যতামূলক।
ডিপেন্ডেন্সি স্ক্যানিং: নিয়মিত npm audit চালান, পুরোনো প্যাকেজ আপডেট রাখুন।
ইনডেক্স না দেওয়া — সবচেয়ে সাধারণ ও মারাত্মক ভুল।
ইভেন্ট লুপ ব্লক করা — ভারী সিঙ্ক্রোনাস কাজ দিয়ে সার্ভার আটকে দেওয়া।
ক্যাশিং না করা — প্রতিবার ডেটাবেস হিট করা।
অকালে microservices — ছোট অ্যাপে অপ্রয়োজনীয় জটিলতা; প্রথমে ভালো monolith বানান, পরে দরকারে ভাঙুন।
মনিটরিং উপেক্ষা করা — সমস্যা ব্যবহারকারীর কাছ থেকে জানা।
সিক্রেট হার্ডকোড করা — নিরাপত্তা দুঃস্বপ্ন।
বাংলাদেশের ফ্রিল্যান্স ও দেশি-বিদেশি ক্লায়েন্ট মার্কেটে স্কেলেবল MERN দক্ষতার চাহিদা প্রবল। শুধু "অ্যাপ বানাতে পারি" বলার চেয়ে "স্কেলেবল, প্রোডাকশন-রেডি অ্যাপ বানাতে পারি" বলতে পারলে আপনার রেট ও বিশ্বাসযোগ্যতা — দুটোই বাড়ে।
বাস্তব পরামর্শ: পোর্টফোলিওতে এমন একটা প্রজেক্ট রাখুন যেখানে আপনি আধুনিক স্ট্যাক (TypeScript, Docker, CI/CD) আর অন্তত একটা স্কেলিং কৌশল (ক্যাশিং বা ইনডেক্সিং) প্রয়োগ করেছেন — এটাই আপনাকে গড় ডেভেলপারদের ভিড় থেকে আলাদা করবে। আর মনে রাখবেন, ক্লায়েন্ট সবসময় সবচেয়ে বেশি ফিচার নয়, বরং নির্ভরযোগ্য ও টেকসই সমাধান খোঁজে।
MERN Stack কি ২০২৬ সালেও প্রাসঙ্গিক? হ্যাঁ, MERN ২০২৬ সালেও স্কেলেবল ওয়েব অ্যাপ তৈরির অন্যতম জনপ্রিয় পছন্দ। আধুনিক টুলিং (TypeScript, Next.js, Docker) যুক্ত হয়ে এটি আগের চেয়ে আরও শক্তিশালী হয়েছে, এবং startup থেকে enterprise পর্যন্ত ব্যাপকভাবে ব্যবহৃত হচ্ছে।
MERN নাকি Next.js — কোনটা বেছে নেব? এটা "এক বা অন্য" নয়। আধুনিক MERN প্রজেক্টে প্রায়ই ফ্রন্টএন্ডে Next.js ব্যবহার করা হয় (SEO ও পারফরম্যান্সের জন্য), আর ব্যাকএন্ডে Node.js + Express + MongoDB থাকে। SEO গুরুত্বপূর্ণ হলে Next.js যোগ করুন।
MERN কত ইউজার পর্যন্ত স্কেল করতে পারে? সঠিকভাবে আর্কিটেক্ট করলে কোটি ব্যবহারকারী পর্যন্ত। মূল চাবিকাঠি হলো ইনডেক্সিং, ক্যাশিং (Redis), হরাইজন্টাল স্কেলিং (লোড ব্যালেন্সার + Kubernetes), এবং প্রয়োজনে MongoDB sharding। Node.js নিজেই LinkedIn, Netflix-এর মতো প্ল্যাটফর্মে ব্যবহৃত হয়।
স্কেল করতে কি শুরু থেকেই microservices দরকার? না। বেশিরভাগ ক্ষেত্রে শুরুতে একটা ভালোভাবে গঠিত monolith যথেষ্ট। অকালে microservices অপ্রয়োজনীয় জটিলতা ও খরচ আনে। অ্যাপ যখন সত্যিই বড় হয় এবং নির্দিষ্ট অংশ আলাদাভাবে স্কেল করার দরকার হয়, তখনই ভাঙুন।
নতুন প্রজেক্টে কোন Node ভার্সন ব্যবহার করব? জুন ২০২৬ অনুযায়ী নতুন প্রোডাকশন কাজের জন্য Node.js 24 (Active LTS) ব্যবহার করুন — এটিতে দীর্ঘ সাপোর্ট, npm 11 ও বিল্ট-ইন TypeScript সাপোর্ট আছে। Node 22 এখনো চলবে, তবে এপ্রিল ২০২৭-এ মেয়াদ শেষ।
অনেকে ভাবেন স্কেলেবিলিটি পরে যোগ করা যাবে। বাস্তবে, স্কেলেবল অ্যাপ তৈরি হয় শুরুর সিদ্ধান্তগুলো থেকে — কীভাবে আপনি স্কিমা ডিজাইন করছেন, কোথায় ইনডেক্স দিচ্ছেন, কীভাবে স্তরগুলো আলাদা করছেন।
ভালো খবর হলো, এর জন্য আপনাকে দিন একে নতুন কিছু শিখতে হবে না — MERN Stack-এর ভিত্তির ওপরই এই কৌশলগুলো দাঁড়িয়ে। আজ থেকে প্রতিটা প্রজেক্টে একটা করে কৌশল যোগ করুন: এই সপ্তাহে ইনডেক্সিং, পরের সপ্তাহে ক্যাশিং, তারপর Docker। কয়েক মাসেই আপনি গড় ডেভেলপার থেকে এমন একজনে পরিণত হবেন, যে কোটি-ব্যবহারকারীর অ্যাপ বানাতে পারে।
প্রশ্নটা MERN পারবে কি না — তা নয়। প্রশ্নটা হলো, আপনি কতটা ভালোভাবে বানাচ্ছেন।