ফুড ডেলিভারি সিস্টেম ডিজাইন

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

ডোরড্যাশ (DoorDash), উবার ইটস (UberEats) বা ফুডপ্যান্ডার (Foodpanda) মতো ফুড ডেলিভারি প্ল্যাটফর্মগুলো সাধারণত তিনটি পক্ষের মধ্যে এক ধরনের সংযোগ স্থাপন করে: ক্রেতা বা কাস্টমার (যারা খাবার চান), রেস্টুরেন্ট (যারা খাবার তৈরি করে), এবং ড্রাইভার বা রাইডার (যারা খাবার ডেলিভারি করে)। এই থ্রি-সাইডেড বা তিন-দিকের মার্কেটপ্লেসের কারণেই সিস্টেমটির ডিজাইন বেশ চ্যালেঞ্জিং হয়ে দাঁড়ায়।

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

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

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

• লো ল্যাটেন্সি (Low latency): কোনো একটি অর্ডার প্লেস করার প্রক্রিয়াটি ২ সেকেন্ডের চেয়ে কম সময়ের মধ্যে সম্পূর্ণ হতে হবে।
• রিয়েল-টাইম ট্র্যাকিং: ড্রাইভারের জিপিএস (GPS) আপডেট প্রতি ৩-৫ সেকেন্ড পরপর হতে হবে, যা ক্রেতারা রিয়েল-টাইমে দেখতে পারবেন।
• পিক টাইম বা ভিড় সামলানো: দুপুরের খাবার এবং রাতের খাবারের সময় ট্রাফিক বেড়ে গেলেও সিস্টেম পারফরম্যান্সের যেন কোনো পতন না হয় সেটি নিশ্চিত করতে হবে।
• সঠিক ETA (Estimated Time of Arrival): খাবার পৌঁছানোর সম্ভাব্য সময় বা ETA-এর সাথে আসল ডেলিভারির সময়ের পার্থক্য যেন ৫ মিনিটের মধ্যে থাকে।

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

চলুন একটি বড় পরিসরের প্ল্যাটফর্মের জন্য এর সাইজ হিসাব করি:

• প্রতিদিন ১০ মিলিয়ন (১ কোটি) অর্ডার — অর্থাৎ গড়ে প্রতি সেকেন্ডে প্রায় ১১৫টি অর্ডার।
• প্ল্যাটফর্মে ১ মিলিয়ন (১০ লাখ) রেস্টুরেন্ট আছে, যার মধ্যে যেকোনো সময়ে প্রায় ২০০K (২ লাখ) রেস্টুরেন্ট অ্যাকটিভ থাকে।
• ৫০০K (৫ লাখ) অ্যাকটিভ ড্রাইভার — যদি প্রতি ৪ সেকেন্ড পর পর লোকেশন আপডেট হয়, তবে প্রতি সেকেন্ডে ১২৫K (১ লাখ ২৫ হাজার) জিপিএস ডেটা রাইট হবে।
• পিক টাইমে ট্রাফিক (Peak load): লাঞ্চ (সকাল ১১টা-দুপুর ১টা) এবং ডিনারের (সন্ধ্যা ৬টা-রাত ৮টা) সময় ট্রাফিক সাধারণ সময়ের চেয়ে ৩-৫ গুণ বেড়ে যায় → অর্থাৎ, ওই সময়ে মিনিটে প্রায় ৫,০০০ অর্ডার প্রসেস করতে হতে পারে।
• ১ মিলিয়ন কনকারেন্ট ট্র্যাকিং সেশন — অর্থাৎ, একই সময়ে ১০ লাখ ব্যবহারকারী ম্যাপে তাদের ডেলিভারি ট্র্যাক করছেন।
• স্টোরেজ: প্রতিটি অর্ডারের সাইজ প্রায় ২ KB (আইটেম, ঠিকানা, স্ট্যাটাসের ইতিহাস)। ১০ মিলিয়ন/দিন × ৩৬৫ দিন × ২ KB ≈ বছরে ৭ TB।

এখানে মূল বাধাটি বা আসল বটলনেক হলো এর রিয়েল-টাইম অংশটি: ড্রাইভারদের ম্যাচ করানো, লোকেশন ট্র্যাকিং করা এবং সঠিক ETA অনুমান করা — এই সবকটি কাজই পিক টাইমে খুব কম ল্যাটেন্সির (latency) মধ্যে নিখুঁতভাবে করতে হবে।

অর্ডার ফ্লো (Order Flow)

একটি ফুড ডেলিভারি অর্ডারের জীবনচক্র বা লাইফ-সাইকেল বেশ কিছু ধাপে বিভক্ত থাকে:

1. ক্রেতার অর্ডার প্লেস করা: ক্রেতা রেস্টুরেন্ট বাছাই করে, কার্টে আইটেম যুক্ত করে এবং পেমেন্ট কনফার্ম করে। এর ফলে সিস্টেমে একটি অর্ডার তৈরি হয়।
2. রেস্টুরেন্টের কনফার্মেশন: রেস্টুরেন্ট অর্ডারের নোটিফিকেশন পেয়ে সেটি গ্রহণ করে এবং খাবার তৈরি হতে কতক্ষণ লাগবে তার একটি আনুমানিক সময় (ধরা যাক, ২০ মিনিট) জানিয়ে দেয়।
3. অর্পন বা ডিসপ্যাচ (Dispatch) করে ড্রাইভার অ্যাসাইন করা: ডিসপ্যাচ সার্ভিস দূরত্ব, বর্তমান ডেলিভারির চাপ এবং রেস্টুরেন্টের খাবার তৈরি করার সময়ের ওপর ভিত্তি করে সবচেয়ে উপযুক্ত ড্রাইভার খুঁজে বের করে। খাবার প্রস্তুত হওয়ার আগেই এটি কোনো ড্রাইভারকে অ্যাসাইন করতে পারে (pre-dispatch)।
4. ড্রাইভারের পিক আপ: ড্রাইভার রেস্টুরেন্টে পৌঁছে খাবার পিক আপ করার বিষয়টি কনফার্ম করে। এই স্ট্যাটাস আপডেট ক্রেতার কাছে রিয়েল-টাইমে পৌঁছায়।
5. ডেলিভারি এবং ট্র্যাকিং: ড্রাইভার ক্রেতার দিকে যাত্রা শুরু করে। কয়েক সেকেন্ড পর পর জিপিএস আপডেট আসতে থাকে। ক্রেতা লাইভ ম্যাপে সম্ভাব্য পৌঁছানোর সময় (ETA) সহ ড্রাইভারকে দেখতে পান।

একটি ডেলিভারি সম্পন্ন হতে এসব প্রতিটি ধাপে পরিবর্তন এলে সংশ্লিষ্ট সবাইকে—ক্রেতা, রেস্টুরেন্ট এবং ড্রাইভার—সব সময় আপডেট রাখার জন্য নোটিফিকেশন পাঠানো হয়।

ডিসপ্যাচ অ্যালগরিদম (Dispatch Algorithm)

সঠিক ড্রাইভার খুঁজে বের করা বা ম্যাচিং করাই হলো এই সিস্টেমের প্রধান কাজ। এটি একটি অপটিমাইজেশন সমস্যা (optimization problem) যা কয়েকটি বিষয়ের ওপর নির্ভর করে পারফেক্ট ব্যালেন্স রাখতে হয়:

• ড্রাইভারের দূরত্ব (Driver proximity): রেস্টুরেন্ট থেকে ড্রাইভার কত দূরে আছেন? জিওস্পেশিয়াল ইনডেক্সিং (যেমন, জিওহ্যাশ বা কোয়াডট্রি) ব্যবহার করে আশেপাশের ড্রাইভারদের খুব সহজেই খুঁজে বের করা হয়।
• খাবার প্রস্তুত করার সময় (Prep time): খাবার তৈরি হতে যদি ২৫ মিনিট সময় লাগে, তবে তখনই ড্রাইভার পাঠানোর কোনো মানে হয় না। ডিসপ্যাচ বা রিকোয়েস্ট পাঠানোর সময়টা এমনভাবে ঠিক করতে হয় যেন খাবার তৈরি হওয়ার ঠিক আগ মুহূর্তেই ড্রাইভার পৌঁছান।
• রাস্তার দূরত্ব (Route distance): শুধুমাত্র সরলরৈখিক দূরত্বের বদলে রাস্তার নেটওয়ার্কের দূরত্ব বিবেচনায় আনা হয়। এক মাইল দূরের কোনো ড্রাইভারকে অনেক জ্যাম পেরিয়ে আসতে ২ মাইল দূরের অন্য একজন ড্রাইভারের (যিনি ফাঁকা রাস্তা দিয়ে আসবেন) চেয়ে বেশি সময় লাগতে পারে।
• ড্রাইভারের বর্তমান কার্যাবলী বা লোড: ড্রাইভার কি ইতিমধ্যে অন্য কোনো অর্ডার নিয়ে ব্যস্ত? একাধিক অর্ডার একসাথে দেওয়া (Batching) সম্ভব, তবে এতে কাজের জটিলতা বাড়ে।

ডিসপ্যাচ ইঞ্জিন কাছাকাছি থাকা ড্রাইভারদের একটি স্কোর বা রেটিং দেয় এবং সবচেয়ে উপযুক্ত জনকে অ্যাসাইন করে। এটি অনেকটা রাইড-শেয়ারিংয়ের (যেমন- উবারের) মতোই কাজ করে, কেবল এর সাথে রেস্টুরেন্টের 'খাবার প্রস্তুতের সময়' (prep time) নামে একটি অতিরিক্ত ভ্যারিয়েবল যোগ হয়। সিস্টেম অনেক সময় প্রি-ডিসপ্যাচ (pre-dispatch) করে — অর্থাৎ আগে থেকেই একজন ড্রাইভারকে অ্যাসাইন করে রাখে, যাতে খাবার তৈরি হওয়ার সাথে সাথেই ড্রাইভার রেস্টুরেন্টে উপস্থিত থাকতে পারেন।

ETA পূর্বানুমান এবং রিয়েল-টাইম ট্র্যাকিং

ETA বা 'খাবার পৌঁছনোর সম্ভাব্য সময়' নির্ধারণ করতে পুরনো ডেটা দিয়ে ট্রেইন করা একটি মেশিন লার্নিং (ML) মডেল ব্যবহার করা হয়:

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

রিয়েল-টাইম ট্র্যাকিং জিপিএসের ক্রমাগত আপডেটের মাধ্যমে কাজ করে:

• ড্রাইভারের অ্যাপ প্রতি ৩-৫ সেকেন্ড পর পর জিপিএস কো-অর্ডিনেট পাঠায়।
• এই আপডেটগুলো সরাসরি মেইন ডেটাবেসে না গিয়ে একটি ড্রাইভার লোকেশন ক্যাশে (Driver Location Cache) (জিওস্পেশিয়াল ফিচারের সুবিধাসহ Redis-এ) জমা হয়।
• ক্রেতার ট্র্যাকিং স্ক্রিন থেকে পোল (poll) করে বা ওয়েব সকেট (WebSocket)-এর মাধ্যমে সর্বশেষ লোকেশন পুশ করে দেখানো হয়।
• ড্রাইভার যত সামনের দিকে এগোয়, ETA তত দ্রুত আপডেট হতে থাকে।

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