হোটেল রিজার্ভেশন সিস্টেম

এই অধ্যায়ে আমরা Marriott International-এর মতো একটি হোটেল চেইনের জন্য একটি হোটেল রিজার্ভেশন সিস্টেম ডিজাইন করবো। এখানে ব্যবহৃত ডিজাইন এবং টেকনিকগুলো অন্যান্য বুকিং-ভিত্তিক সিস্টেম ডিজাইন প্রশ্নেও প্রযোজ্য, যেমন:

• Airbnb ডিজাইন করা
• ফ্লাইট রিজার্ভেশন সিস্টেম ডিজাইন করা
• মুভি টিকিট বুকিং সিস্টেম ডিজাইন করা

স্টেপ ১ - সমস্যা বোঝা এবং ডিজাইন স্কোপ নির্ধারণ

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

ক্যান্ডিডেট: সিস্টেমের স্কেল কতটা হবে?
ইন্টারভিউয়ার: ধরুন আমরা এমন একটি ওয়েবসাইট তৈরি করছি যেখানে ৫,০০০টি হোটেল এবং মোট ১ মিলিয়ন রুম আছে।

ক্যান্ডিডেট: কাস্টমাররা কি বুকিং করার সময় পেমেন্ট করবে নাকি হোটেলে গিয়ে?
ইন্টারভিউয়ার: সরলতার জন্য ধরুন বুকিং করার সময়ই সম্পূর্ণ পেমেন্ট করা হবে।

ক্যান্ডিডেট: কাস্টমাররা কি শুধু হোটেলের ওয়েবসাইট থেকে বুক করবে? ফোন কল বা অন্য মাধ্যম লাগবে কি?
ইন্টারভিউয়ার: ধরুন বুকিং শুধু ওয়েবসাইট এবং অ্যাপ থেকে করা যাবে।

ক্যান্ডিডেট: কাস্টমাররা কি বুকিং বাতিল (cancel) করতে পারবে?
ইন্টারভিউয়ার: হ্যাঁ।

ক্যান্ডিডেট: আর কি কিছু বিবেচনা করতে হবে?
ইন্টারভিউয়ার: হ্যাঁ, আমরা ১০% overbooking অনুমতি দেই। Overbooking মানে হলো হোটেল তার আসল রুম সংখ্যার চেয়ে বেশি বুকিং নিতে পারে, কারণ কিছু কাস্টমার সাধারণত cancel করে।

ক্যান্ডিডেট: আমি ধরে নিচ্ছি room search স্কোপের বাইরে থাকবে। আমরা ফোকাস করবো:

• হোটেল পেজ দেখানো
• রুম ডিটেইল পেজ দেখানো
• রুম রিজার্ভ করা
• অ্যাডমিন প্যানেল (add/update/remove হোটেল ও রুম)
• overbooking সাপোর্ট করা

ইন্টারভিউয়ার: ঠিক আছে।

ইন্টারভিউয়ার: আরেকটি বিষয়, হোটেলের দাম dynamicভাবে পরিবর্তিত হয়। হোটেল কতটা full তার উপর ভিত্তি করে রুমের দাম প্রতিদিন আলাদা হতে পারে।

ক্যান্ডিডেট: আমি এটা মাথায় রাখবো।

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

• High concurrency support করতে হবে (peak season বা event সময় অনেক বুকিং)
• Moderate latency acceptable (কয়েক সেকেন্ড delay হলেও চলবে)

ব্যাক-অফ-দ্য-এনভেলপ এস্টিমেশন

• মোট হোটেল: ৫,০০০
• মোট রুম: ১ মিলিয়ন

ধরি:

• ৭০% রুম occupied
• average stay = ৩ দিন

দৈনিক রিজার্ভেশন:

(1,000,000 × 0.7) / 3 ≈ 233,333 ≈ ~240,000

রিজার্ভেশন প্রতি সেকেন্ড (TPS):

240,000 / 100,000 seconds ≈ ~3 TPS

👉 অর্থাৎ average reservation load খুব বেশি না।

পুরো সিস্টেমের QPS বিশ্লেষণ

একটি সাধারণ ইউজার ফ্লো:

1. হোটেল/রুম ডিটেইল পেজ দেখা (query)
2. বুকিং কনফার্মেশন পেজ দেখা (query)
3. রুম বুক করা (transaction)

ধরি:

• ১০% ইউজার পরের স্টেপে যায়
• ৯০% drop off করে
• কোনো prefetching নেই

QPS ফানেল (Figure 1)

• Reserve rooms (final): 3 QPS
• Booking page: 30 QPS
• Detail page: 300 QPS

সারসংক্ষেপ

ইউজার সংখ্যা ধাপে ধাপে কমে যায়, তাই funnel pattern তৈরি হয়—শুরুতে বেশি traffic, শেষে কম transaction।