ই-কমার্স প্ল্যাটফর্ম ডিজাইন

সমস্যাটি বোঝা

অ্যামাজনের (Amazon) মতো ই-কমার্স প্ল্যাটফর্মগুলো অভাবনীয় রকমের অনেক চ্যালেঞ্জ সামলে থাকে: সুবিশাল প্রোডাক্ট ক্যাটালগ, বিদ্যুতের বেগে সার্চ করা, রিয়েল-টাইমে ইনভেন্টরি বা মজুতের খোঁজ রাখা, শপিং কার্ট, পেমেন্ট প্রোসেসিংয়ের সাথে চেকআউট এবং সবশেষে অর্ডার ডেলিভারি করা।

চলুন আমাদের রিকয়ারমেন্টগুলো দেখে নিই:

ফাংশনাল রিকয়ারমেন্টস:

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

নন-ফাংশনাল রিকয়ারমেন্টস:

• ৯৯.৯৯% আপটাইম: ডাউনটাইম মানে হলো রেভিনিউ লস — ফ্ল্যাশ সেলের সময় এক মিনিট সাইট ডাউন থাকলেও কোটি টাকার ক্ষতি হতে পারে।
• সাব-সেকেন্ড সার্চ: প্রোডাক্ট সার্চ করার ২০০ মি.সে. এর মধ্যে রেজাল্ট দেখাতে হবে। নয়তো ৩ সেকেন্ড দেরি হলেই ব্যবহারকারীরা সাইট থেকে চলে যান।
• ফ্ল্যাশ সেলের ক্যাপাসিটি: পিক ইভেন্টগুলোতে (যেমন: ব্ল্যাক ফ্রাইডে, প্রাইম ডে) মিনিটে ১ লাখ (100K) অর্ডার সামলানোর ক্ষমতা থাকতে হবে।
• ইনভেন্টরির জন্য স্ট্রং কনসিস্টেন্সি (Strong consistency): স্টকে বা মজুতে যতটুকু আছে কখনোই তার চেয়ে বেশি বেচাকেনা করা যাবে না। স্টকের চেয়ে বেশি বিক্রি (Overselling) করা বেশ ঝামেলার এবং এটি গ্রাহকের বিশ্বাস নষ্ট করে।

প্রাথমিক একটা হিসাব-নিকাশ

চলুন সিস্টেমটার সাইজের একটি হিসাব করি:

• ক্যাটালগে লাখ লাখ বিক্রেতার প্রায় ৫০০ মিলিয়ন (৫০ কোটি) প্রোডাক্ট রয়েছে।
• ডেইলি অ্যাকটিভ ইউজার (DAU) হলো ১০০ মিলিয়ন (১০ কোটি), যারা ব্রাউজ, সার্চ এবং কেনাকাটা করছেন।
• প্রতিদিন গড়ে ১০ মিলিয়ন (১ কোটি) অর্ডার হয় — যা প্রতি সেকেন্ডে প্রায় ১১৫টি অর্ডার।
• পিক টাইম: ফ্ল্যাশ সেলের সময় প্রতি মিনিটে ১ লাখ (100K) অর্ডার — মানে প্রতি সেকেন্ডে প্রায় ১,৭০০ অর্ডার।
• প্রতিদিন ১ বিলিয়ন (১০০ কোটি) সার্চ কোয়েরি — প্রায় ১১,৫০০ কোয়েরি/সেকেন্ড, আর পিক টাইমে প্রায় ৩০K/সেকেন্ড।
• প্রোডাক্ট ডেটা: ৫০০ মিলিয়ন × ~৫ KB (টাইটেল, ডেসক্রিপশন, ছবির মেটাডেটা) = ক্যাটালগের জন্য ~২.৫ TB।
• অর্ডার ডেটা: প্রতিদিন ১০ মিলিয়ন × ৩৬৫ দিন × ~২ KB = ~৭.৩ TB/বছর।
• ছবির স্টোরেজ: ৫০০ মিলিয়ন প্রোডাক্ট × ৫টি ছবি × ৫০০ KB = ~১.২৫ PB (CDN এর মাধ্যমে সার্ভ করা হবে)।

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

ডেটা মডেলস

প্ল্যাটফর্মটি মূলত যেসব এনটিটি দিয়ে চলে:

প্রোডাক্ট (Product):

• SKU (ইউনিক আইডেন্টিফায়ার), title, description, price, category, brand
• images[] (CDN-এর URL), attributes (সাইজ, কালার, ওজন)
• seller_id, rating, review_count, created_at

কার্ট (Cart):

• user_id, items[] (প্রতিটির জন্য SKU, quantity, price_snapshot)
• updated_at — কার্টগুলো অস্থায়ী হয়, দ্রুত রেসপন্স পাওয়ার জন্য এগুলোকে Redis-এ স্টোর করে রাখা হয়।

অর্ডার (Order):

• order_id, user_id, items[], total_amount
• status (pending → paid → shipped → delivered), payment_id
• shipping_address, created_at, updated_at

ইনভেন্টরি (Inventory):

• SKU, warehouse_id, quantity_available, quantity_reserved
• last_updated — এটি সবচেয়ে গুরুত্বপূর্ণ একটি টেবিল যেখানে স্ট্রং কনসিস্টেন্সি প্রয়োজন।

ইনভেন্টরি ম্যানেজমেন্ট বা স্টক ব্যবস্থাপনা

ই-কমার্সের সবচেয়ে কঠিন অংশ হলো ইনভেন্টরির হিসাব ঠিক রাখা। এর কোর প্যাটার্ন হলো আগে রিজার্ভ করা, এরপর কমিট করা (reserve-then-commit):

1. রিজার্ভ (Reserve): যখন চেকআউট শুরু হয়, তখন quantity_available (موجود আছে) অ্যাটমিক্যালি কমিয়ে quantity_reserved (রিজার্ভ করা হয়েছে) বাড়িয়ে দেওয়া হয়। ডিস্ট্রিবিউটেড লকিং (Redis SETNX) অথবা অপটিমিস্টিক কনকারেন্সি (CAS-এর সাথে ভার্সন কলাম) ব্যবহার করুন।
2. কমিট (Commit): পেমেন্ট সফল হওয়ার পর, একে reserved থেকে sold-এ সরিয়ে নিন।
3. রিলিজ (Release): পেমেন্ট ফেইল করলে বা রিজার্ভেশনের নির্দিষ্ট সময় (TTL - ১০ মিনিট) পার হয়ে গেলে, রিজার্ভ করা স্টক আবার অ্যাভেইলেবল বা মজুত স্টকে ফিরিয়ে আনুন।

কনসিস্টেন্সি মডেল (Consistency model):

• ক্যাটালগ ডেটা: ইভেনচুয়াল কনসিস্টেন্সি (Eventual consistency)। কয়েক সেকেন্ড দেরিতে প্রোডাক্টের ডেসক্রিপশন আপডেট হওয়াটা মেনে নেওয়া যায়।
• ইনভেন্টরি/চেকআউট: স্ট্রং কনসিস্টেন্সি (Strong consistency) বা নিখুঁত হিসেব প্রয়োজন আছে। ইনভেন্টরি টেবিলে রো-লেভেল লক (row-level lock) সহ ডেটাবেস ট্রানজেকশন ব্যবহার করুন। UPDATE inventory SET qty = qty - 1 WHERE sku = ? AND qty > 0 — পার্টিকুলারলি WHERE qty > 0 অংশটি অ্যাটমিক্যালি ওভারসেলিং বা মজুতের চেয়ে বেশি বিক্রি আটকে দেয়।
• কার্ট ডেটা: ইভেনচুয়াল কনসিস্টেন্সি। কার্টগুলো একটি নির্দিষ্ট সময় (TTL) দিয়ে Redis-এ স্টোর করে রাখা হয় — যদি Redis নোড কোনো কারণে ডাউন হয়ে যায়, তবে একটি পারসিস্টেন্ট বা স্থায়ী ব্যাকআপ থেকে কার্টটি রিকভার করা যায়।

সার্চ এবং ফ্ল্যাশ সেল

সার্চ আর্কিটেকচার:

• ইলাস্টিক সার্চ (Elasticsearch) ক্লাস্টার সমস্ত ৫০০ মিলিয়ন প্রোডাক্ট ইন্ডেক্স করে। প্রোডাক্ট ডেটাবেস থেকে চেঞ্জ ডেটা ক্যাপচার (CDC) পাইপলাইনের মাধ্যমে প্রোডাক্টের আপডেটগুলো আসে, যা সার্চ ইন্ডেক্সকে বলতে গেলে প্রায় রিয়েল-টাইমে সিঙ্ক করে রাখে।
• ফ্যাসেটেড সার্চ (Faceted search): ইলাস্টিক সার্চ এই কাজে দারুণ — মূল্যসীমা (price range), ব্র্যান্ড, ক্যাটাগরি, রেটিং এবং আরও অনেক কিছু দিয়ে একটিমাত্র কোয়েরিতে ফিল্টার করুন।
• পার্সোনালাইজড র‍্যাংকিং: একটি র‍্যাংকিং সার্ভিস ব্যবহারকারীর আগের কেনাকাটার ইতিহাস, সাইট ব্রাউজিং, এবং বিক্রেতার প্রাসঙ্গিকতার উপর ভিত্তি করে সার্চ রেজাল্টের ক্রম ঠিক করে।

ফ্ল্যাশ সেল সামলানো:

• কিউ-ভিত্তিক (Queue-based) চেকআউট: ফ্ল্যাশ সেল চলার সময় চেকআউটের রিকোয়েস্টগুলোকে একটি মেসেজ কিউতে (যেমন Kafka) রাখুন। ওয়ার্কাররা একটির পর একটি রিকোয়েস্ট প্রসেস করবে, এতে ইনভেন্টরি নিয়ে কোনো রেস কন্ডিশন (race condition) তৈরি হবে না।
• ইনভেন্টরি প্রি-অ্যালোকেশন: সেল শুরু হওয়ার আগে, ইনভেন্টরিকে কয়েকটি শার্ডে বা ভাগে প্রি-অ্যালোকেট করুন। প্রতিটি চেকআউট ওয়ার্কার একটি শার্ডের দায়িত্ব নেবে — এর ফলে ক্রস-শার্ড লকিংয়ের কোনো প্রয়োজন হবে না।
• রেট লিমিটিং (Rate limiting): বট আক্রমণ ঠেকাতে প্রতি ইউজারের জন্য চেকআউট রিকোয়েস্টের একটি সীমা ঠিক করে দিন। API গেটওয়েতে একটি টোকেন বাকেট (token bucket) রেট লিমিটার ব্যবহার করুন।
• CDN + স্ট্যাটিক পেইজ: ফ্ল্যাশ সেলের আইটেমগুলোর প্রোডাক্ট পেইজ আগে থেকেই রেন্ডার করে CDN থেকে সার্ভ করা হয়। শুধুমাত্র "Buy" বাটনে চাপ দিলে একটি রিকোয়েস্ট ব্যাকএন্ডে হিট করে।