कोडिंग इंटरव्यू: रेस्टोरेंट टेबल रिज़र्वेशन मॉड्यूल डिज़ाइन करें

प्रॉम्प्ट और उपयुक्त संदर्भ

यह एक लो-लेवल डिज़ाइन और कोडिंग प्रश्न है। इसका उद्देश्य रिज़र्वेशन, टेबल, समय अंतराल और प्रतीक्षा सूची को स्पष्ट उत्तरदायित्वों वाले ऑब्जेक्ट्स में बदलना है। सार्वजनिक साक्षात्कार रिपोर्टों में रेस्टोरेंट रिज़र्वेशन डिज़ाइन शामिल रहा है, जबकि OOD गाइड स्कोप को स्पष्ट करने, आवश्यकताओं को सूचीबद्ध करने और फिर ऑब्जेक्ट्स और इंटरफेस चुनने पर जोर देते हैं। एक ही रेस्टोरेंट, निश्चित खुलने का समय और इन-मेमरी मॉड्यूल मानकर चलें; यदि साक्षात्कारकर्ता पूछे तो पर्सिस्टेंस और कॉनक्रेन्सी नियंत्रण जोड़ें।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

• क्या आप Restaurant, Table, Reservation, Waitlist और आवंटन नीति को अलग करते हैं।
• क्या आप हाफ-ओपन अंतराल, क्षमता, टेबल संयोजन और रद्दीकरण के बाद रिलीज़ को सही ढंग से संभालते हैं।
• क्या आप एक स्टेट मशीन, इडेम्पोटेंट अनुरोध और कॉनक्रेन्सी के तहत कोई दोहरा असाइनमेंट न होना डिज़ाइन करते हैं।
• क्या परीक्षण सीमाओं को कवर करते हैं और क्या आप जटिलता और विस्तार बिंदुओं की व्याख्या कर सकते हैं।

पहले पूछे जाने वाले स्पष्टीकरण

पूछें कि क्या मेहमान कोई विशिष्ट टेबल चुनते हैं या केवल पार्टी का आकार, और क्या टेबल को जोड़ा जा सकता है। रिज़र्वेशन अवधि और सफाई बफ़र, संपादन, देर से आगमन, नो-शो, वॉक-इन, प्रतीक्षा सूची क्रम और अनुरोध पुनः प्रयासों को स्पष्ट करें। समय की सटीकता, समय क्षेत्र, एकल बनाम एकाधिक रेस्टोरेंट, और क्या क्रॉस-प्रोसेस पर्सिस्टेंस की आवश्यकता है, इसकी पुष्टि करें।

30-सेकंड उत्तर ढांचा

मैं पहले एक इम्यूटेबल TimeRange और रिज़र्वेशन स्टेट मशीन को परिभाषित करूंगा। AvailabilityService टकराव संबंधी प्रश्नों को संभालता है, TableAllocator क्षमता और नीति के आधार पर चयन करता है, ReservationService निर्माण, रद्दीकरण और सूचनाओं का समन्वय करता है, और Waitlist उम्मीदवारों को अलग से प्रबंधित करता है। निर्माण में एक इडेम्पोटेंसी कुंजी का उपयोग किया जाता है और टेबल पर कब्जा करने से पहले उसी क्रिटिकल सेक्शन के भीतर उपलब्धता की दोबारा जांच की जाती है। रद्दीकरण केवल वैध परिवर्तनों की अनुमति देता है और क्षमता को रिलीज़ करता है। परीक्षण आसन्न अंतरालों, समवर्ती अनुरोधों, बार-बार रद्दीकरण और प्रतीक्षा सूची पदोन्नति को कवर करते हैं।

चरण-दर-चरण गहन उत्तर

1. समय, टेबल और रिज़र्वेशन स्थितियों का मॉडल बनाएं

एक रिज़र्वेशन को हाफ-ओपन अंतराल [start, end) के साथ दर्शाएं, जिसके लिए start < end आवश्यक है। दो अंतराल तब ओवरलैप होते हैं जब a.start < b.end && b.start < a.end। Table क्षमता, पहचानकर्ता और उपलब्धता संग्रहीत करता है; Reservation अतिथि, पार्टी का आकार, अंतराल, टेबल और स्थिति संग्रहीत करता है। स्थितियां HELD, CONFIRMED, SEATED, CANCELLED और NO_SHOW हो सकती हैं; अमान्य परिवर्तनों को अस्वीकार करें।

2. आवंटन को बदलने योग्य बनाएं

TableAllocator उम्मीदवार टेबल और एक अनुरोध प्राप्त करता है। डिफ़ॉल्ट रूप से यह सबसे छोटी उपयुक्त टेबल चुनता है, जिससे बर्बादी से बचा जा सके; अन्य नीतियां आसन्न टेबल या सुलभता को प्राथमिकता दे सकती हैं। एलोकेटर रिज़र्वेशन नहीं लिखता है, जिससे एक विशाल क्लास बनाने के बजाय खोज, निर्णय और पर्सिस्टेंस अलग रहते हैं।

3. टकराव जांच और निर्माण लागू करें

रेस्टोरेंट, अंतराल और टेबल इंडेक्स द्वारा फ़िल्टर करें, फिर एलोकेटर को चुनने दें। निर्माण इनपुट को मान्य करता है, सफाई बफ़र लागू करता है, एक इडेम्पोटेंसी कुंजी बनाता है, और लिखने से पहले एक लॉक या लेनदेन के भीतर उपलब्धता को फिर से पढ़ता है। यह पुराने खोज परिणाम पर भरोसा नहीं कर सकता। इनवेरिएंट स्पष्ट है: एक टेबल में शून्य ओवरलैपिंग CONFIRMED रिज़र्वेशन होते हैं।

create(request, key):
  if idempotency.exists(key): return idempotency.result(key)
  range = TimeRange(request.start, request.end + cleanupBuffer)
  lock(restaurantId, range):
    table = allocator.choose(availableTables(range), request.partySize)
    if table is null: return WAITLISTED
    reservation = Reservation.confirm(request, table, range)
    store(reservation)
    idempotency.save(key, reservation.id)
    return reservation

4. रद्दीकरण, देरी और पदोन्नति को संभालें

रद्दीकरण केवल HELD या CONFIRMED को CANCELLED बनने की अनुमति देता है; इसे दोहराने पर वही परिणाम मिलता है और डुप्लिकेट सूचनाएं नहीं भेजी जाती हैं। आगमन स्थिति को SEATED में बदल देता है; एक नीति टाइमआउट इसे NO_SHOW बना सकता है और टेबल को रिलीज़ कर सकता है। एक WaitlistMatcher रिलीज़ इवेंट्स का उपभोग करता है, प्रतीक्षा समय, पार्टी के आकार और प्राथमिकता के अनुसार मिलान करता है, फिर उसी निर्माण क्रिटिकल सेक्शन का पुन: उपयोग करता है ताकि कोई नया रिज़र्वेशन टेबल को दोहरा असाइन न कर सके।

5. परीक्षण करें और जटिलता की व्याख्या करें

परीक्षण करें कि आसन्न [19:00,20:00) और [20:00,21:00) अंतरालों में कोई टकराव न हो, रिवर्स इनपुट अस्वीकार कर दिया जाए, सफाई बफ़र टकराव का विस्तार करे, दोहराई गई इडेम्पोटेंसी कुंजी कोई अतिरिक्त रिज़र्वेशन न बनाए, रद्दीकरण अधिकतम एक बार पदोन्नत करे, और समवर्ती निर्माण में केवल एक विजेता हो। यदि प्रत्येक टेबल क्रमबद्ध रिज़र्वेशन संग्रहीत करती है, तो एक टेबल के लिए टकराव लुकअप O(log n + k) है; m उम्मीदवार टेबल के साथ, चयन और लेखन लगभग O(m log n) हैं। क्षमता बकेट या अंतराल इंडेक्स इसे बेहतर बना सकते हैं।

उच्च गुणवत्ता वाला नमूना उत्तर

मैं एक इम्यूटेबल हाफ-ओपन TimeRange, एक स्पष्ट रिज़र्वेशन स्टेट मशीन और एक बदलने योग्य आवंटन नीति का मॉडल बनाऊंगा। AvailabilityService रेस्टोरेंट, समय और टेबल द्वारा फ़िल्टर करता है; TableAllocator सबसे छोटी पर्याप्त टेबल चुनता है; ReservationService एक इडेम्पोटेंसी कुंजी का उपयोग करके एक लॉक या लेनदेन के भीतर दोबारा पढ़ता है और लिखता है। रद्दीकरण, देरी और नो-शो वैध परिवर्तनों के माध्यम से क्षमता को रिलीज़ करते हैं, और प्रतीक्षा सूची मिलान उसी क्रिटिकल सेक्शन का पुन: उपयोग करता है। परीक्षण आसन्न अंतरालों, सफाई बफ़र, बार-बार रद्दीकरण, समवर्ती निर्माण और प्रतीक्षा सूची रेस को कवर करते हैं, जिसमें इंडेक्स की गई जटिलता बताई गई है।

सामान्य गलतियां

• अस्पष्ट उत्तरदायित्वों और नीति प्रतिस्थापन के बिना सभी लॉजिक को Restaurant में डालना।
• बंद अंतरालों का उपयोग करना और आसन्न रिज़र्वेशन को गलत तरीके से टकराव के रूप में चिह्नित करना।
• उपलब्धता की खोज करना और बाद में राइट बाउंड्री पर दोबारा जांच किए बिना लिखना।
• रद्दीकरण को गैर-इडेम्पोटेंट बनाना ताकि पुनः प्रयास टेबल को रिलीज़ कर दें या दो बार सूचित करें।
• केवल अतिथि बुकिंग लागू करना जबकि वॉक-इन, देरी, नो-शो और प्रतीक्षा सूचियों को अनदेखा करना।
• इनवेरिएंट, सीमा परीक्षण या जटिलता के बिना केवल एक क्लास आरेख दिखाना।

फॉलो-अप प्रश्न और उत्तर

आप संयुक्त टेबल का समर्थन कैसे करेंगे?

एक tableId के बजाय एक क्रमित टेबल सेट लौटाएं, जिसमें कुल क्षमता, जुड़ने की क्षमता और पूरे सेट में टकराव के लिए बाधाएं जोड़ी जाएं। एलोकेटर इंटरफ़ेस को बनाए रखें और एक ComposableTableAllocator कार्यान्वयन जोड़ें।

आप विभिन्न प्रक्रियाओं में डबल बुकिंग को कैसे रोकते हैं?

टेबल और समय पर एक सत्यापन योग्य लॉक या ट्रांज़ैक्शनल बाधा के साथ टकराव इनवेरिएंट को पर्सिस्टेंस में ले जाएं। एक एप्लिकेशन लॉक टकराव को कम कर सकता है लेकिन यह शुद्धता की एकमात्र गारंटी नहीं हो सकता।

क्या होगा यदि कोई उपयोगकर्ता बार-बार निर्माण पर क्लिक करता है?

एक क्लाइंट इडेम्पोटेंसी कुंजी की आवश्यकता रखें और परिणाम को रेस्टोरेंट और उपयोगकर्ता स्कोप द्वारा संग्रहीत करें। वही कुंजी मूल रिज़र्वेशन लौटाती है; एक अलग कुंजी अभी भी साझा टकराव जांच से गुजरती है। दर सीमित करना (रेट लिमिटिंग) व्यावसायिक इडेम्पोटेंसी का विकल्प नहीं है।

आप एक लोकप्रिय डिनर स्लॉट को कैसे अनुकूलित करेंगे?

रेस्टोरेंट और समय के अनुसार शार्ड करें। कैशे का उपयोग केवल खोज संकेतों के लिए करें; अंतिम निर्माण एक दृढ़ता से सुसंगत क्रिटिकल सेक्शन में रहता है। पूर्व-गणना की गई क्षमता बकेट और प्रतीक्षा सूची के उम्मीदवारों को लिखने से पहले संस्करण जांच की आवश्यकता होती है।

क्या होगा यदि रद्दीकरण के बाद सूचना विफल हो जाती है?

स्थिति परिवर्तन और एक आउटबॉक्स इवेंट को एक ही लेनदेन में कमिट करें; सूचना उपभोक्ताओं को इडेम्पोटेंट और पुन: प्रयास योग्य बनाएं। टेबल को रिलीज़ करने के लिए SMS की सफलता का इंतज़ार नहीं करना चाहिए; विफलताएं पुन: प्रयास और ऑपरेटर को दिखाई देने वाले डेड-लेटर कतार में जाती हैं।