সেলফ-হোস্টেড কমার্স প্ল্যাটফর্ম স্কেল করা: দিনে ১০০ থেকে ১,০০,০০০ অর্ডারের সার্ভার রোডম্যাপ

প্রতিটি সেলফ-হোস্টেড কমার্স প্ল্যাটফর্ম একইভাবে শুরু হয়: একটি সার্ভার, একটি ডেটাবেস, আর একজন মানুষ যিনি জানেন কোথায় কী আছে। শুরু করার সঠিক পথ এটাই। এটি সস্তা, সহজ, আর প্রথম হাজার গ্রাহকের জন্য যথেষ্ট দ্রুত।

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

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

প্রথম নীতি: স্কেল করার আগে মাপুন

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

• p95 রেসপন্স টাইম — হোম পেজ, পণ্যের পেজ, কার্ট ও চেকআউটের জন্য। গড় হিসাব সেই ধীর রিকোয়েস্টগুলো লুকিয়ে রাখে যেগুলোতে বিক্রি হারায়।
• ডেটাবেসের লোড: সক্রিয় কানেকশন, ধীর কোয়েরি (১০০ মিলিসেকেন্ডের বেশি যেকোনো কিছু) আর ক্যাশ হিট রেশিও।
• কিউয়ের গভীরতা ও বয়স: কতগুলো জব অপেক্ষায়, আর সবচেয়ে পুরোনোটা কত পুরোনো।
• মেমরি ও সোয়াপ প্রতিটি হোস্টে, সঙ্গে কার্নেল লগে আউট-অব-মেমরি কিল।
• এরর রেট: প্রতি মিনিটে 5xx রেসপন্স আর প্রতি ঘণ্টায় ব্যর্থ জব।

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

ধাপ ১ — এক বাক্সে সব (দিনে প্রায় ১,০০০ অর্ডার পর্যন্ত)

৪টি vCPU, ৮ জিবি র‍্যাম আর দ্রুত SSD স্টোরেজসহ একটি ভার্চুয়াল সার্ভার অবাক করার মতো বড় ব্যবসা চালাতে পারে। কন্টেইনার একে গুছিয়ে রাখে: ওয়েব (nginx-এর পেছনে PHP-FPM), PostgreSQL, Redis, একটি কিউ ওয়ার্কার আর একটি শিডিউলার।

এই ধাপে যা ঠিক রাখতে হবে

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

প্রথমে কী ভাঙে

মেমরি। ভারী রিপোর্ট, ইমপোর্ট বা ছবির ব্যাচ র‍্যামের জন্য চেকআউটের সঙ্গে প্রতিযোগিতা করে। আপনি দেখবেন এলোমেলোভাবে পেজ ধীর হচ্ছে, আর শেষে কার্নেল কোনো প্রসেস মেরে ফেলছে। শিডিউলার প্রায়ই এর শিকার: একে আলাদা মেমরি লিমিট দিন (৫১২ এমবি একটি যুক্তিসংগত ন্যূনতম) এবং প্রতি মিনিটে নতুন প্রসেস চালুর বদলে একটি দীর্ঘস্থায়ী শিডিউলার প্রসেস চালান।

ধাপ ২ — ভূমিকা অনুযায়ী ভাগ (দিনে প্রায় ১,০০০ থেকে ১০,০০০ অর্ডার)

পরের ধাপ "একই সার্ভার আরও বড়" নয়। এটি হলো ভূমিকাগুলো আলাদা করা, যাতে তারা একে অপরের সঙ্গে প্রতিযোগিতা বন্ধ করে।

ভূমিকা	কেন আলাদা হয়	সাধারণ আকার
ডেটাবেস হোস্ট	নিজের ডিস্ক I/O আর ক্যাশের জন্য মেমরি; কোলাহলপূর্ণ প্রতিবেশী নেই।	৪–৮ vCPU, ১৬–৩২ জিবি র‍্যাম, NVMe
Redis হোস্ট	লোডের মধ্যেও সেশন, ক্যাশ ও কিউ দ্রুত থাকে।	২ vCPU, ৪–৮ জিবি র‍্যাম
ওয়েব নোড	সিপিইউ-নির্ভর PHP কাজ, আলাদাভাবে স্কেল হয়।	প্রতিটি ২–৪ vCPU
কিউ ওয়ার্কার	প্রতি কিউর জন্য আলাদা পুল, যাতে ইমেইল কখনো পেমেন্ট আটকে না দেয়।	প্রতি পুলে ২ vCPU

অতিথিরা যে পেজ দেখেন, সেগুলো ক্যাশ করুন

স্টোরের বেশিরভাগ ট্রাফিক বেনামি: মানুষ পণ্য আর ক্যাটাগরি ঘুরে দেখছেন। এসব পেজ কয়েক মিনিটের জন্য পূর্ণ HTML হিসেবে অ্যাপ্লিকেশন ও CDN-এ ক্যাশ করা যায়। দুটি নিয়ম কষ্টদায়ক বাগ ঠেকায়:

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

প্রথমে কী ভাঙে

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

ধাপ ৩ — স্কেল আউট (দিনে প্রায় ১০,০০০ থেকে ৫০,০০০ অর্ডার)

এখন একটি লোড ব্যালান্সারের পেছনে একাধিক একই রকম ওয়েব নোড চলে। সিস্টেমকে ওয়েব স্তরে স্টেটলেস হতে হবে: সেশন Redis-এ, আপলোড অবজেক্ট স্টোরেজে, কোনো ওয়েব নোডের লোকাল ডিস্কে গুরুত্বপূর্ণ কিছু নয়।

এই ধাপে যে অংশগুলো গুরুত্বপূর্ণ

• কানেকশন পুলিং (PgBouncer)। শত শত অ্যাপ্লিকেশন কানেকশন কয়েক ডজন আসল ডেটাবেস কানেকশন ভাগ করে নেয়। প্রায়ই এটাই স্থিতিশীলতার সবচেয়ে বড় জয়।
• রিপোর্টের জন্য রিড রেপ্লিকা। ড্যাশবোর্ড, এক্সপোর্ট আর অ্যানালিটিক্স রেপ্লিকা থেকে পড়ে, তাই ভারী রিপোর্ট কখনো চেকআউট ধীর করে না।
• মিডিয়া ও ব্যাকআপের জন্য অবজেক্ট স্টোরেজ। S3 বা Cloudflare R2-এর মতো সামঞ্জস্যপূর্ণ সেবা, CDN-এর মাধ্যমে পরিবেশিত। ওয়েব নোডগুলো ছবি পরিবেশন পুরোপুরি বন্ধ করে।
• আলাদা SSR রেন্ডারার। সার্ভার-সাইড রেন্ডারিং পেজকে দ্রুত ও সার্চ ইঞ্জিনে খুঁজে পাওয়ার যোগ্য করে, কিন্তু এটি PHP থেকে ভিন্ন ধরনের কাজ। আলাদাভাবে স্কেল করুন।
• কিউ তত্ত্বাবধান। একটি ড্যাশবোর্ড (যেমন Laravel Horizon) যা প্রতি কিউর থ্রুপুট, ব্যর্থতা ও অপেক্ষার সময় দেখায়, অ্যালার্টসহ।

প্রথমে কী ভাঙে

ক্যাশ স্ট্যাম্পিড আর হট রো। একটি জনপ্রিয় ক্যাশ এন্ট্রির মেয়াদ শেষ হলে শত শত রিকোয়েস্ট একই মুহূর্তে সেটি আবার বানাতে চায়। লক বা "stale-while-revalidate" ব্যবহার করুন, যাতে একটি রিকোয়েস্ট নতুন করে বানায় আর বাকিরা পুরোনো মান দেয়। আলাদাভাবে, যে সারি সবাই আপডেট করে — ফ্ল্যাশ সেলের পণ্যের স্টক কাউন্টার, একটি সিকোয়েন্স নম্বর — তা অপেক্ষমাণ ট্রানজ্যাকশনের লাইনে পরিণত হয়। এসব আপডেট ছোট ও অ্যাটমিক রাখুন।

ধাপ ৪ — একটি ফ্লিট (দিনে ৫০,০০০+ অর্ডার)

এই আকারে কারিগরি প্যাটার্নগুলো সুপরিচিত। যা বদলায় তা হলো এগুলোর চারপাশের শৃঙ্খলা।

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

ডাউনটাইম ছাড়া ডিপ্লয়: ব্লু/গ্রিন

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

1. একবার বিল্ড। প্রতি কমিটে একটি ইমেজ, CI-তে পরীক্ষিত, স্টেজিং থেকে প্রোডাকশনে অপরিবর্তিত অবস্থায় যায়।
2. গ্রিন চালু করুন চলমান ব্লু কন্টেইনারের পাশে।
3. শুধু যোগ করার মাইগ্রেশন। কলাম ও টেবিল যোগ করুন; একই রিলিজে কখনো রিনেম বা ড্রপ নয়। পুরোনো কোডকে নতুন স্কিমার সঙ্গে চলতে হবে।
4. ওয়ার্ম ও চেক। কনফিগ ও রুট ক্যাশ করুন, হেলথ এন্ডপয়েন্টে হিট দিন, একটি ছোট স্মোক টেস্ট চালান।
5. সুইচ করুন গেটওয়ে আপস্ট্রিম রিলোড দিয়ে, রিস্টার্ট দিয়ে নয়, যাতে কোনো কানেকশন না ছিঁড়ে।
6. ব্লু রাখুন দ্রুত রোলব্যাকের জন্য। পুরোনো কলাম পরের রিলিজে সরান, যখন কিছু আর সেগুলো পড়ে না।

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

ব্যাকআপ, RPO ও RTO সহজ ভাষায়

দুটি সংখ্যা আপনার ব্যাকআপ কৌশল ঠিক করে, আর সেগুলো বেছে নেবে ব্যবসা — আইটি নয়:

• RPO (রিকভারি পয়েন্ট অবজেক্টিভ): কতটা ডেটা হারানো আপনার পক্ষে সহনীয়। প্রতি রাতে ব্যাকআপ মানে সর্বোচ্চ ২৪ ঘণ্টার অর্ডার।
• RTO (রিকভারি টাইম অবজেক্টিভ): রিস্টোরের সময় কতক্ষণ অফলাইন থাকতে পারেন।

ধাপ	যুক্তিসংগত RPO	যুক্তিসংগত RTO	কীভাবে
১	২৪ ঘণ্টা	৪ ঘণ্টা	প্রতি রাতে ডাম্প + ফাইল অবজেক্ট স্টোরেজে
২	১ ঘণ্টা	১ ঘণ্টা	প্রতি ঘণ্টায় স্ন্যাপশট, স্ক্রিপ্ট করা রিস্টোর
৩–৪	কয়েক মিনিট	৩০ মিনিটের কম	অবিরাম WAL আর্কাইভিং, স্ট্যান্ডবাই রেপ্লিকা

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

পাঁচটি ফাঁদ যা আমি বারবার দেখি

1. CDN-এ 404 ক্যাশ হয়ে যাওয়া। কোনো পেজ ছবিটি চাওয়ার পরে আপলোড করলে CDN কয়েক ঘণ্টা "পাওয়া যায়নি" দেখাতে পারে। আগে ফাইল লিখুন, পরে লিংক দিন।
2. এক ডেটাবেসে পাস, আরেকটিতে ফেল করা টেস্ট। টেস্টে SQLite আর প্রোডাকশনে PostgreSQL কেস-সেনসিটিভ সার্চ, টাইপ তুলনা আর enum পরিবর্তনে একমত নয়। অন্তত একটি CI জব প্রোডাকশন ইঞ্জিনে চালান।
3. প্রোডাকশন হোস্টে ভারী বিল্ড চালানো। একসঙ্গে দুটি অ্যাসেট বিল্ড মেমরি শেষ করে স্টোর বন্ধ করে দিতে পারে। CI-তে বিল্ড করুন, ইমেজ পাঠান।
4. সাধারণ শেল "&" দিয়ে চালানো ব্যাকগ্রাউন্ড প্রসেস। সেশনের সঙ্গে এরা মরে যায়। সুপারভাইজার বা কন্টেইনার রানটাইম ব্যবহার করুন।
5. প্রোডাকশনে ডিবাগ টুল চালু রেখে দেওয়া। কোয়েরি লিসেনার আর প্রোফাইলার প্রতিটি রিকোয়েস্টে কাজ যোগ করে, আর ভুলে যাওয়া একটি মনিটর সপ্তাহের পর সপ্তাহ চুপচাপ একটি সিপিইউ খেয়ে ফেলতে পারে।

আজই ব্যবহারযোগ্য একটি সক্ষমতা চেকলিস্ট

• সবচেয়ে ব্যস্ত ঘণ্টায় p95 চেকআউট টাইম ৮০০ মিলিসেকেন্ডের কম।
• পিকে ডেটাবেস সিপিইউ ৬০%-এর নিচে; চেকআউট পথে কোনো কোয়েরি ১০০ মিলিসেকেন্ডের বেশি নয়।
• পেমেন্ট ও নোটিফিকেশনের সবচেয়ে পুরোনো কিউড জব ৬০ সেকেন্ডের কম।
• পিকে প্রতিটি হোস্টে অন্তত ৩০% মেমরি খালি; গত সপ্তাহে শূন্য OOM কিল।
• শেষ রিস্টোর টেস্ট ৩০ দিনের কম আগে।
• প্রতিটি রিলিজ ডাউনটাইম ছাড়া ডিপ্লয় ও ফেরত নেওয়া যায়।

বিশেষভাবে StoreConsole-এর জন্য হার্ডওয়্যার পরিকল্পনা করলে, সিস্টেম রিকোয়ারমেন্টস পেজে প্রতিটি ধাপের প্রস্তাবিত আকার আছে, আর ডকুমেন্টেশনে ডকার, কিউ ও শিডিউলারের বিস্তারিত।

মূল কথা

• স্কেল করুন যখন কোনো মেট্রিক বলে: p95 লেটেন্সি, ডেটাবেস লোড, কিউর বয়স, মেমরি, এরর রেট।
• ধাপ ১ একটি ভালোভাবে টিউন করা বাক্স। ধাপ ২ ভূমিকা ভাগ করে। ধাপ ৩ পুলিং, রেপ্লিকা ও অবজেক্ট স্টোরেজ দিয়ে স্কেল আউট। ধাপ ৪ শৃঙ্খলার ব্যাপার।
• ধীর কাজ রিকোয়েস্টের পথ থেকে দূরে রাখুন; কোনো ক্রেতা যেন কিউ জবের জন্য অপেক্ষা না করেন।
• শুধু যোগ করার মাইগ্রেশনসহ ব্লু/গ্রিন ডিপ্লয় করুন, আর রোলব্যাকের জন্য পুরোনো সংস্করণ প্রস্তুত রাখুন।
• RPO ও RTO ব্যবসাকে বেছে নিতে দিন, তারপর নির্ধারিত সময়ে রিস্টোর পরীক্ষা করুন।

আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। তিনি বাড়তে থাকা ব্যবসার জন্য কমার্স ও ইআরপি সিস্টেম ডিজাইন করেন, যার মূল জোর ইভেন্ট-ড্রিভেন আর্কিটেকচার, ডেটার নির্ভুলতা আর সেলফ-হোস্টেড পরিচালনায়।