सिस्टम डिज़ाइन इंटरव्यू: हाई-डिमांड टिकट बुकिंग सिस्टम डिज़ाइन करें

प्रॉम्प्ट और लागू संदर्भ

कंसर्ट, खेल आयोजनों, या हाई-डिमांड प्रदर्शनियों के लिए एक टिकट बुकिंग सिस्टम डिज़ाइन करें। एक इवेंट में 50,000 असाइन की गई सीटें हैं। सेल के पहले पाँच मिनट में 20 लाख यूज़र्स आते हैं, और एज ट्रैफ़िक पीक पर 50,000 रिक्वेस्ट प्रति सेकंड तक पहुँच जाता है। सिस्टम एक साथ 10,000 से अधिक सीट-मैप शॉपर्स को अनुमति नहीं देता है और प्रति सेकंड 2,000 होल्ड प्रयासों और 1,000 पेमेंट ऑथराइजेशन को संभालता है। एक होल्ड पाँच मिनट तक रहता है; एक होल्ड की गई सीट जिसे खरीदा नहीं गया है, उसे फिर से बिक्री योग्य बनाया जाना चाहिए।

मान लें कि पेमेंट प्रोवाइडर अलग-अलग ऑथराइजेशन और कैप्चर का समर्थन करता है। सीट-मैप का p99 लक्ष्य 500 मिलीसेकंड से कम, होल्ड क्रिएशन 300 मिलीसेकंड से कम, और ऑर्डर-स्टेटस रीड्स 200 मिलीसेकंड से कम है। अराइवल वॉल्यूम, लेटेंसी लक्ष्य, होल्ड अवधि, और पेमेंट दर इंटरव्यू के अनुमान हैं, किसी टिकटिंग कंपनी के प्रकाशित बेंचमार्क नहीं। मूल शुद्धता (कॉर्टेक्टनेस) का नियम यह है कि एक इवेंट में एक सीट अधिकतम एक वैध सोल्ड (बेचे गए) ऑर्डर से संबंधित हो सकती है। जब उपलब्धता बिगड़ती है, तो सर्विस एडमिशन रोक सकती है या होल्ड अस्वीकार कर सकती है; इसे इन्वेंट्री का अनुमान लगाकर बिक्री जारी नहीं रखनी चाहिए।

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

इंटरव्यूअर क्या मूल्यांकन करता है

पहला संकेत यह है कि क्या उम्मीदवार कतार की निष्पक्षता (क्यू फेयरनेस) को इन्वेंट्री की शुद्धता (इन्वेंट्री करेक्टनेस) से अलग करता है। एक वर्चुअल वेटिंग रूम ओरिजिन की सुरक्षा करता है और सेल में प्रवेश को नियंत्रित करता है। यह दो एडमिट किए गए खरीदारों को एक ही सीट का अनुरोध करने से नहीं रोक सकता। आधिकारिक इन्वेंट्री ट्रांजेक्शन को अंतिम अपवर्जन (एक्सक्लूजन) प्रदान करना होगा।

दूसरा संकेत डेटाबेस रो लॉक और बिज़नेस होल्ड के बीच का अंतर है। एक PostgreSQL रो लॉक एक छोटे ट्रांजेक्शन के अंदर होता है और ट्रांजेक्शन समाप्त होने पर रिलीज़ हो जाता है। जिस पाँच मिनट में खरीदार विवरण दर्ज करता है और भुगतान करता है, उस दौरान कनेक्शन और ट्रांजेक्शन को खुला रखना असुरक्षित है। लंबे समय के व्यावसायिक अर्थ का hold_id और expires_at के साथ टिकाऊ (ड्यूरेबल) स्टेट होना चाहिए।

तीसरा संकेत समय- और पुनः प्रयास (रीट्राई)-सचेत स्टेट ट्रांज़िशन है। एक विलंबित एक्सपायरी वर्कर को ऐसी सीट रिलीज़ नहीं करनी चाहिए जिसे अब एक नए खरीदार ने होल्ड कर रखा है या जिसे बेचा जा चुका है। क्लाइंट टाइमआउट को दूसरा होल्ड या पेमेंट नहीं बनाना चाहिए। प्रत्येक ट्रांज़िशन वर्तमान स्थिति, स्वामी (ओनर), संस्करण (वर्जन), और समय सीमा (डेडलाइन) की जांच करता है, जबकि एक इडेम्पोटेंसी कुंजी मूल परिणाम को पुनः प्राप्त करती है।

चौथा संकेत एक सही पेमेंट बाउंड्री है। ऑथराइजेशन सफल हो सकता है जबकि स्थानीय कन्फर्मेशन विफल हो जाता है; एक सोल्ड ट्रांजेक्शन कमिट हो सकता है जबकि उसका रिस्पॉन्स खो जाता है; कैप्चर अपने वेबहुक आने से पहले सफल हो सकता है। मजबूत उत्तर ऑर्डर और पेमेंट-ऑपरेशन रिकॉर्ड को सुरक्षित रखते हैं और लुकअप, वेबहुक, और सामंजस्य (रिकंसीलिएशन) के माध्यम से कन्वर्ज होते हैं। वे लापता रिस्पॉन्स को विफलता नहीं मानते हैं।

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

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• क्या सीटें असाइन की गई हैं या जनरल एडमिशन हैं? असाइन की गई सीटिंग के लिए प्रति सीट एक्सक्लूसिव स्टेट की आवश्यकता होती है। जनरल एडमिशन को प्रति टिकट टियर में उपलब्ध मात्रा के रूप में एक सशर्त डिक्रिमेंट (कंडीशनल डिक्रिमेंट) के साथ बेहतर ढंग से मॉडल किया जाता है जो नेगेटिव नहीं हो सकता।
• क्या मल्टी-सीट रिक्वेस्ट सभी-या-कुछ-नहीं (ऑल-ऑर-नथिंग) होनी चाहिए? इस प्रॉम्प्ट के लिए एक से छह सीटों के ऑल-ऑर-नथिंग होल्ड की आवश्यकता है। आंशिक सफलता प्राइसिंग, रिलीज़ व्यवहार, और खरीदार के अनुभव को बदल देती है।
• कतार की निष्पक्षता नीति (फेयरनेस पॉलिसी) क्या है? FIFO पहले आने वालों को प्राथमिकता देता है; रैंडम रिलीज़ मिलीसेकंड-स्तरीय नेटवर्क अंतरों के प्रभाव को कम करती है। नीति का खुलासा किया जाना चाहिए और इसे स्थिर रहना चाहिए, न कि सेल के बीच में बदलकर फिर भी क्रमित निष्पक्षता का दावा करना चाहिए।
• क्या पेमेंट ऑथराइजेशन और कैप्चर को अलग किया जा सकता है? यदि हाँ, तो ऑथराइज़ करें, सीटों की पुष्टि करें, फिर कैप्चर करें। तत्काल कैप्चर के लिए पैसे कटने के बाद सीट कन्फर्मेशन विफल होने पर कंपेंसेशन की आवश्यकता होती है।
• प्रति-खाता टिकट सीमा क्या है? इसे होल्ड और ऑर्डर कन्फर्मेशन दोनों पर लागू करें। केवल ब्राउज़र-स्तरीय प्रतिबंध को बायपास किया जा सकता है।
• क्या कई क्षेत्र (रीजन) एक ही इवेंट पर राइट कर सकते हैं? बेस डिज़ाइन प्रत्येक इवेंट के लिए एक राइट होम असाइन करता है और अन्य जगहों से ब्राउज़िंग और कतार की सेवा करता है। समवर्ती मल्टी-रीजन राइट्स के लिए क्रॉस-रीजन सर्वसम्मति (कंसेंसस) या प्री-एलोकेटेड इन्वेंट्री की आवश्यकता होती है और यह लेटेंसी और विफलता व्यवहार दोनों को बदल देता है।
• सीट मैप कितना ताज़ा (फ्रेश) होना चाहिए? यदि कुछ सेकंड की बासीपन (स्टेलनेस) स्वीकार्य है, तो एक स्नैपशॉट प्लस डेल्टास का उपयोग करें। प्रदर्शित प्रत्येक AVAILABLE स्टेट तब तक केवल सलाहकारी रहती है जब तक कि होल्ड ट्रांजेक्शन सफल न हो जाए।
• क्या होगा यदि पेमेंट ऑथेंटिकेशन जारी रहने के दौरान होल्ड समाप्त हो जाए? एक एकल सीमित PAYMENT_PENDING ग्रेस पीरियड परिभाषित करें। हमेशा के लिए नवीनीकृत न करें या पेमेंट परिणाम अज्ञात होने पर पुनर्विक्रय न करें।

30-सेकंड उत्तर का ढांचा (फ़्रेमवर्क)

“मैं 20 लाख आगंतुकों को एक इवेंट-स्कोप वाले वर्चुअल वेटिंग रूम में रखूंगा और केवल इन्वेंट्री शार्ड, पेमेंट प्रोवाइडर, और टिकट जारीकर्ता द्वारा समर्थित दर पर शॉर्ट-लिव्ड हस्ताक्षरित (साइंड) एडमिशन टोकन जारी करूंगा। ब्राउज़िंग और सीट मैप CDN, कैशिंग, और वर्जन्ड डेल्टा का उपयोग करते हैं; होल्ड राइट्स इवेंट के एकल आधिकारिक डेटाबेस शार्ड में जाते हैं। एक छोटा ट्रांजेक्शन चयनित सीटों को क्रमबद्ध (सॉर्टेड) क्रम में लॉक करता है और केवल तभी डेटाबेस-समय के पाँच मिनट के एक्सपायरी के साथ एक hold_id लिखता है जब प्रत्येक सीट उपलब्ध या एक्सपायर्ड हो। चेकआउट के दौरान कोई डेटाबेस लॉक खुला नहीं रहता है। एक विलंबित कतार एक्सपायरी क्लीनअप को गति देती है, लेकिन रिलीज़ अभी भी सशर्त रूप से होल्ड, स्टेट, और डेडलाइन से मेल खाती है। पेमेंट पहले ऑथराइज़ करने के लिए एक स्थिर ऑपरेशन ID का उपयोग करता है। ऑथराइजेशन के बाद, एक ट्रांजेक्शन होल्ड को फिर से मान्य करता है और कैप्चर से पहले सीटों, ऑर्डर, और आउटबॉक्स को बेचे गए (सोल्ड) के रूप में कमिट करता है। कोई भी टाइमआउट अज्ञात हो जाता है और वेबहुक, लुकअप, और सामंजस्य के माध्यम से कन्वर्ज होता है। मैं इस डिज़ाइन को एक ही सीट के लिए विवाद (कंटेंशन), एक्सपायरी/पेमेंट रेस, छूटे हुए रिस्पॉन्स, डुप्लिकेट संदेशों, और शार्ड विफलताओं के साथ साबित करूंगा।”

चरण-दर-चरण गहन विश्लेषण (डीप डाइव)

चरण 1: वॉल्यूम को एडमिशन-कंट्रोल टारगेट में बदलें

300 सेकंड में 20 लाख अराइवल्स का औसत लगभग 6,667 प्रति सेकंड होता है। 50,000-रिक्वेस्ट-प्रति-सेकंड एज पीक से पता चलता है कि शुरुआती क्षण और ब्राउज़र रीफ्रेश औसत से कहीं अधिक बर्स्टी हैं। इन्वेंट्री का बजट प्रति सेकंड केवल 2,000 होल्ड प्रयासों और 1,000 पेमेंट ऑथराइजेशन के लिए रखा गया है, इसलिए एज रीट्राई सीधे इन्वेंट्री सर्विस तक नहीं पहुँच सकते हैं।

प्रत्येक होल्ड में छह सीटें तक हो सकती हैं, इसलिए 2,000 रिक्वेस्ट प्रति सेकंड के कारण विवादों और रोलबैक से पहले प्रति सेकंड 12,000 तक सीट-रो निर्णय हो सकते हैं। क्षमता परीक्षणों के लिए एक विषम (स्क्यूड) हॉट-सेक्शन वितरण की आवश्यकता होती है; उन 12,000 निर्णयों को 50,000 सीटों पर समान रूप से फैलाने से कंटेंशन छिप जाएगा।

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

Cloudflare का सार्वजनिक वेटिंग-रूम दस्तावेज़ उस टाइमस्टैम्प से FIFO ऑर्डरिंग का वर्णन करता है जिस पर एक विज़िटर पहली बार किसी सक्रिय कतार तक पहुँचता है और एक यादृच्छिक (रैंडम) मोड जो प्रतीक्षारत आगंतुकों का चयन करता है। ये उत्पाद नीतियां हैं, डेटाबेस कंसिस्टेंसी तंत्र नहीं। यहाँ तक कि FIFO को भी समय की ग्रैन्युलैरिटी, पुन: कनेक्ट करने, कई उपकरणों, क्लॉक अथॉरिटी, और बॉट्स के लिए स्पष्ट नियमों की आवश्यकता होती है। यह वैश्विक नेटवर्क पर पूर्ण रिक्वेस्ट-दर-रिक्वेस्ट क्रम का वादा नहीं कर सकता।

चरण 2: ब्राउज़िंग, सीट व्यू, और आधिकारिक इन्वेंट्री को अलग करें

इवेंट विवरण, स्थिर स्थल का नक्शा (वेन्यू मैप), और मूल्य निर्धारण स्पष्टीकरण CDN या कैश में रह सकते हैं। सीट व्यू स्थिति डेल्टा के साथ एक वर्जन्ड स्नैपशॉट को जोड़ता है। एक क्लाइंट को पहले एक snapshot_version प्राप्त होता है, फिर वह एक seat_id, नई स्थिति, और उच्चतर वर्जन वाले परिवर्तनों को लागू करता है। यह डिस्कनेक्ट या वर्जन गैप के बाद स्नैपशॉट को रीलोड करता है। यदि 10,000 सक्रिय खरीदार हर पाँच सेकंड में पोल करते हैं, तो वे प्रति सेकंड लगभग 2,000 रीड उत्पन्न करते हैं। डेल्टा डिलीवरी बार-बार फुल-मैप रीड्स को कम करती है, लेकिन यह इन्वेंट्री का सोर्स ऑफ ट्रुथ नहीं बनती है।

सीट मैप संक्षिप्त रूप से बासी (स्टेल) हो सकता है। एक खरीदार AVAILABLE देख सकता है और फिर भी होल्ड रेस हार सकता है। डेटाबेस अनुपलब्ध होने के दौरान कैश किसी बिक्री की पुष्टि नहीं कर सकता है या पुराने डेटा से होल्ड स्वीकार नहीं कर सकता है। यह अत्यधिक उपलब्ध ब्राउज़िंग पाथ को दृढ़ता से सुसंगत (स्ट्रॉन्गली कंसिस्टेंट) इन्वेंट्री राइट पाथ से अलग करता है।

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

चरण 3: API, स्टेट, और इनवेरिएंट्स को परिभाषित करें

कोर API छोटा रह सकता है:

POST /events/{eventId}/holds
  { seatIds, idempotencyKey, admissionToken }
  -> { holdId, status, expiresAt, seats }

POST /holds/{holdId}/checkout
  { paymentMethodToken, idempotencyKey }
  -> { orderId, paymentStatus, nextAction }

GET /orders/{orderId}
  -> { orderStatus, paymentStatus, seats }

एक न्यूनतम डेटा मॉडल है:

SeatInventory(event_id, seat_id, price_version, status,
              hold_id, hold_expires_at, order_id, version)
Hold(hold_id, event_id, account_id, status, expires_at,
     idempotency_key, request_digest, created_at)
Order(order_id, hold_id, account_id, amount_minor, currency,
      status, payment_operation_id, created_at)
PaymentOperation(operation_id, order_id, provider_reference,
                 kind, status, idempotency_key, updated_at)
Outbox(event_id, aggregate_id, event_type, payload, published_at)

महत्वपूर्ण इनवेरिएंट्स हैं:

one (event_id, seat_id) has at most one valid SOLD order
all seats in one hold share the event, account, and expiry
only the current hold_id may move HELD to SOLD or release it
order confirmation revalidates price version, quantity, limit, and total
one idempotency key describes one immutable request; changed parameters are rejected

पैसे मुद्रा की छोटी इकाई (माइनर यूनिट) में एक पूर्णांक (इंटीजर) है। क्लाइंट द्वारा सबमिट किया गया कुल आधिकारिक नहीं है; सर्वर लॉक किए गए मूल्य संस्करण से इसकी पुनर्गणना करता है। एक admission_token सेल में प्रवेश की अनुमति देता है, किसी सीट का स्वामित्व नहीं।

चरण 4: एक छोटे ट्रांजेक्शन के साथ एटॉमिक मल्टी-सीट होल्ड बनाएं

एक रिक्वेस्ट अधिकतम छह सीटों का चयन करती है। ट्रांजेक्शन seat_id द्वारा सॉर्ट करता है, फिर उस निश्चित क्रम में पंक्तियों को SELECT ... FOR UPDATE से लॉक करता है, जिससे विपरीत लॉक ऑर्डर के कारण होने वाले डेडलॉक कम हो जाते हैं। यदि प्रत्येक पंक्ति AVAILABLE या एक्सपायर हो चुका HELD है, तो ट्रांजेक्शन सभी पंक्तियों पर समान hold_id और expires_at = database_now + 5 minutes लिखता है और Hold प्लस आउटबॉक्स इवेंट सम्मिलित करता है। यदि एक पंक्ति बेची गई है या किसी अन्य गैर-एक्सपायर्ड होल्ड से संबंधित है, तो पूरा ट्रांजेक्शन रोलबैक हो जाता है।

स्थिति और डेडलाइन प्रेडिकेट्स के साथ एक सशर्त UPDATE एक अन्य वैध कार्यान्वयन है, बशर्ते सर्विस यह जांचे कि अपडेट की गई पंक्ति संख्या अनुरोधित संख्या के बराबर है। दोनों दृष्टिकोणों में, निर्णय और राइट को एक आधिकारिक ट्रांजेक्शन साझा करना होगा। Redis लॉक प्राप्त करना और डेटाबेस को एसिंक्रोनस रूप से लिखना दो सोर्स ऑफ ट्रुथ बनाता है जब एक सफल होता है और दूसरा विफल हो जाता है। "उपलब्ध" पढ़ना और फिर बिना शर्त लिखना मूल रेस कंडीशन को बनाए रखता है।

PostgreSQL दस्तावेज करता है कि रो लॉक समान पंक्तियों पर राइटर्स और लॉकर्स को ब्लॉक करते हैं और ट्रांजेक्शन समाप्त होने पर रिलीज़ हो जाते हैं। खरीदार का पाँच मिनट का चेकआउट इसलिए टिकाऊ डेटा स्टेट है, पाँच मिनट का डेटाबेस ट्रांजेक्शन नहीं। कनेक्शन को तुरंत कमिट और रिलीज़ करें, फिर बाद के प्रत्येक ट्रांज़िशन के लिए एक नया छोटा ट्रांजेक्शन खोलें।

होल्ड परिणाम के साथ इडेम्पोटेंसी रिकॉर्ड को कमिट करें। यदि सर्विस होल्ड को कमिट करती है और उत्तर देने से पहले क्रैश हो जाती है, तो उसी idempotencyKey के साथ एक पुनः प्रयास मूल holdId लौटाता है। एक नई कुंजी एक नई रेस में प्रवेश करती है। एक रिक्वेस्ट डाइजेस्ट स्टोर करें ताकि उसी कुंजी का उपयोग सीटों के किसी भिन्न समूह के लिए पुन: उपयोग न किया जा सके।

चरण 5: कार्य (जॉब्स) लेट होने पर भी एक्सपायरी को सही बनाएं

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

रिलीज़ ऑपरेशन इस तरह दिखना चाहिए:

UPDATE seat_inventory
SET status = 'AVAILABLE', hold_id = NULL, hold_expires_at = NULL
WHERE event_id = :eventId
  AND hold_id = :holdId
  AND status = 'HELD'
  AND hold_expires_at <= database_now;

विलंबित संदेश डुप्लिकेट, देर से, या क्रम से बाहर हो सकते हैं। यदि एक नया hold_id अब सीट का मालिक है, तो पुराना प्रेडिकेट अब मेल नहीं खाता है। यदि सीट SOLD है, तो इसकी स्थिति अब मेल नहीं खाती है। केवल seat_id द्वारा रिलीज़ करने से किसी अन्य खरीदार का वैध होल्ड हटाया जा सकता है।

अतिरिक्त पेमेंट ऑथेंटिकेशन होल्ड की समय सीमा के करीब पहुँच सकता है। ऑथराइजेशन शुरू होने से पहले, यह डिज़ाइन एक वैध होल्ड के Hold.status को एक सीमित ग्रेस एक्सटेंशन के साथ एटॉमिक रूप से PAYMENT_PENDING में ले जा सकता है। ग्रेस ऑक्यूपेंसी अभी भी सक्रिय इन्वेंट्री और खाता सीमाओं के विरुद्ध गिनी जाती है। एक परिणाम जो नई समय सीमा पर भी अज्ञात रहता है, वह समाधान (रिकंसीलिएशन) में प्रवेश करता है; क्लाइंट सीटों को रोककर रखने के लिए अनिश्चित काल तक विस्तार नहीं कर सकता है।

चरण 6: स्टेट मशीन में अज्ञात पेमेंट परिणाम डालें

चेकआउट एक स्थिर payment_operation_id बनाता है और प्रोवाइडर के साथ अपनी इडेम्पोटेंसी कुंजी का पुन: उपयोग करता है। Stripe का सार्वजनिक API दस्तावेज़ बताता है कि समान इडेम्पोटेंसी कुंजी के साथ किसी रिक्वेस्ट को पुनः प्रयास करने पर पहले अनुरोध का सहेजा गया परिणाम वापस मिलता है। PaymentIntent-शैली के ऑब्जेक्ट उन भुगतानों के लिए लाइफ़साइकिल स्थिति भी प्रकट करते हैं जिन्हें अतिरिक्त प्रमाणीकरण या एसिंक्रोनस पूर्णता की आवश्यकता हो सकती है।

इस क्रम का उपयोग करें:

1. एक छोटे ट्रांजेक्शन में, होल्ड, टिकट सीमा, मूल्य और डेडलाइन को मान्य करें, फिर Order और ऑथराइजेशन ऑपरेशन बनाएं। यदि ग्रेस पीरियड की आवश्यकता है, तो उसी ट्रांजेक्शन में Hold.status को PAYMENT_PENDING में ले जाएं।
2. ट्रांजेक्शन के बाहर पेमेंट ऑथराइजेशन को कॉल करें। एक टाइमआउट UNKNOWN बन जाता है; यह दूसरा ऑपरेशन नहीं बनाता है।
3. कन्फर्म ऑथराइजेशन के बाद, सीटों को फिर से लॉक करें, hold_id का मिलान करें, सभी सीटों को SOLD पर सेट करें, ऑर्डर को CONFIRMED पर सेट करें, और एक ट्रांजेक्शन में आउटबॉक्स इवेंट लिखें।
4. कमिट के बाद कैप्चर करें। बार-बार कैप्चर करने पर समान ऑपरेशन ID का उपयोग होता है। टिकट जारी करना केवल कमिट किए गए कन्फर्मेशन इवेंट का उपभोग करता है।
5. यदि ऑथराइजेशन सफल रहा लेकिन होल्ड की पुष्टि नहीं की जा सकी, तो ऑथराइजेशन को रद्द (वॉइड) कर दें। यदि सोल्ड ट्रांजेक्शन कमिट हो गया और कैप्चर अज्ञात है, तो वेबहुक, सक्रिय लुकअप और रिकंसीलिएशन के कन्वर्ज होने तक सीटों और ऑर्डर को सुरक्षित रखें। उन्हें रिलीज़ करके दोबारा न बेचें। यदि कैप्चर निश्चित रूप से विफल हो गया है और इसका पुन: प्रयास नहीं किया जा सकता है, तो ऑर्डर रद्द करें और टिकट जारी करने से पहले एक ऑडिटेड कंपेंसेशन ट्रांजेक्शन में उसकी सीटों को रिलीज़ करें।

यह ऑर्डरिंग एक अस्थायी "सोल्ड, कैप्चर पेंडिंग" स्थिति की अनुमति देती है लेकिन कभी भी दो खरीदारों को एक ही सीट नहीं देती है। यदि व्यवसाय केवल तुरंत कैप्चर कर सकता है, तो एक सफल चार्ज के बाद विफल सोल्ड ट्रांजेक्शन के लिए एक ऑडिट योग्य वॉइड या रिफंड की आवश्यकता होती है। यह प्रोवाइडर क्षमता ग्राहक और परिचालन जोखिम को बढ़ाती है और इसे स्पष्ट रूप से बताया जाना चाहिए।

सीट और ऑर्डर स्टेट मोनोटोनिक रूप से आगे बढ़ते हैं। सफलता पृष्ठ पर ब्राउज़र रीडायरेक्ट टिकट जारी करने को अधिकृत नहीं कर सकता है। केवल एक सत्यापित प्रोवाइडर रिस्पॉन्स, वेबहुक, या सक्रिय लुकअप ही पेमेंट स्थिति को आगे बढ़ाता है। प्रोवाइडर इवेंट ID द्वारा वेबहुक को डिडुप्लिकेट करें और केवल कानूनी ट्रांज़िशन स्वीकार करें।

चरण 7: डिज़ाइन विफलताएं, स्केलिंग और डिग्रेडेशन

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

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

चरण 8: फ़ॉल्ट इंजेक्शन के साथ इनवेरिएंट्स को सत्यापित करें

फ़ीचर परीक्षणों के अतिरिक्त, मशीन-जांच योग्य गुणों का दावा करें:

count(valid SOLD orders for one seat) <= 1
every CONFIRMED order owns exactly its recorded seats
every SOLD seat points to one CONFIRMED or payment-reconciling order
an expiry action changes only its own hold_id
replaying one idempotent request does not create new business state

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

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

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

“मैं समस्या को ट्रैफ़िक सुरक्षा और इन्वेंट्री शुद्धता में विभाजित करूँगा। पाँच मिनट में 20 लाख अराइवल्स का औसत लगभग 6,667 प्रति सेकंड है, जिसमें 50,000-रिक्वेस्ट-प्रति-सेकंड एज पीक है, जबकि इन्वेंट्री केवल 2,000 होल्ड प्रयास प्रति सेकंड स्वीकार करती है। मैं एक इवेंट-स्कोप वाला वर्चुअल वेटिंग रूम बनाऊँगा। यह एज पर रीफ़्रेश ट्रैफ़िक को अवशोषित करता है और इवेंट शार्ड और पेमेंट पाथ के स्वास्थ्य के अनुसार शॉर्ट-लिव्ड, खाता-बाध्य (अकाउंट-बाउंड) एडमिशन टोकन जारी करता है। कतार का क्रम एक स्पष्ट उत्पाद नीति है; यह सीट एक्सक्लूजन प्रदान नहीं करता है।

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

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

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

स्केलिंग इवेंट-स्कोप वाली है: सामान्य इवेंट्स शार्ड्स साझा करते हैं, हॉट इवेंट्स को समर्पित संसाधन मिलते हैं, और एक इवेंट का एक राइट होम होता है। यदि डेटाबेस, पेमेंट प्रोवाइडर, या जारीकर्ता धीमा हो जाता है, तो वेटिंग रूम एडमिशन कम कर देता है और होल्ड रोक सकता है। सत्यापन के लिए, हज़ारों क्लाइंट एक सीट और ओवरलैपिंग सीट सेट के लिए प्रतिस्पर्धा करते हैं, जबकि मैं देर से एक्सपायरी, कमिट के बाद क्रैश, खोए हुए पेमेंट रिस्पॉन्स, डुप्लिकेट वेबहुक, कैश हानि, और प्राइमरी विफलता इंजेक्ट करता हूँ। डिज़ाइन केवल तभी पास होता है जब यह प्रति सीट अधिकतम एक वैध सोल्ड ऑर्डर साबित करता है, रीप्ले से कोई नई स्थिति नहीं बनती है, और पुरानी एक्सपायरी कार्रवाई द्वारा कोई नया होल्ड नहीं बदला जाता है।”

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

• Redis में लॉक करना और इन्वेंट्री को एसिंक्रोनस रूप से लिखना → लॉक और डेटाबेस राइट्स असहमत हो सकते हैं, जिससे दो अधिकारी बनते हैं → एक आधिकारिक डेटाबेस ट्रांजेक्शन में स्थिति, टिकाऊ होल्ड, और इडेम्पोटेंट परिणाम निष्पादित करें।
• पाँच मिनट के चेकआउट के लिए रो लॉक बनाए रखना → लंबे ट्रांजेक्शन कनेक्शन का उपभोग करते हैं, राइटर्स को ब्लॉक करते हैं, और परित्याग (अबैंडनमेंट) के बाद खराब तरीके से ठीक होते हैं → केवल ट्रांज़िशन के लिए लॉक का उपयोग करें और चेकआउट को टिकाऊ होल्ड स्थिति के साथ दर्शाएं।
• यह मान लेना कि वर्चुअल वेटिंग रूम ओवरसेलिंग को रोकता है → यह एडमिशन को नियंत्रित करता है जबकि एडमिट किए गए खरीदार अभी भी उन्हीं पंक्तियों पर विवाद करते हैं → इन्वेंट्री ट्रांजेक्शन में एक्सक्लूजन को अलग से लागू करें।
• केवल सीट ID द्वारा एक्सपायरी रिलीज़ करना → एक देर से आया संदेश एक नए होल्ड या सोल्ड स्टेट को मिटा सकता है → hold_id, स्थिति, और डेडलाइन का एक साथ मिलान करें।
• चार्ज करना क्योंकि सीट मैप उपलब्ध दिखाता है → रीड मॉडल बासी हो सकता है और दूसरा खरीदार पहले जीत सकता है → भुगतान से पहले आधिकारिक होल्ड प्राप्त करें।
• पेमेंट टाइमआउट के बाद नई कुंजी के तहत रिलीज़ करना और पुन: प्रयास करना → पहला ऑपरेशन सफल हो सकता था, जिससे पुनर्विक्रय या दोहरा शुल्क लग सकता है → अज्ञात स्थिति को सुरक्षित रखें, ऑपरेशन ID का पुन: उपयोग करें, और वेबहुक, लुकअप, और सामंजस्य के माध्यम से कन्वर्ज करें।
• हॉट इवेंट की प्रत्येक सीट को यादृच्छिक रूप से शार्ड करना → एक मल्टी-सीट होल्ड कई शार्ड्स में फैल जाता है और सरल एटॉमिकता खो देता है → किसी इवेंट को एक राइट शार्ड पर तब तक रखें जब तक कि मापी गई क्षमता यह साबित न कर दे कि अधिक जटिल इन्वेंट्री पार्टीशन आवश्यक है।
• सख्त वैश्विक FIFO का वादा करना → नेटवर्क लेटेंसी, रीकनेक्ट्स, डिवाइस बदलना, और बॉट्स देखने योग्य क्रम को बदल देते हैं → कतार ग्रैन्युलैरिटी, पहचान, रीकनेक्ट, और जोखिम नीतियों को एक सत्यापन योग्य निष्पक्षता अनुबंध के रूप में परिभाषित करें।
• केवल औसत थ्रूपुट का लोड-परीक्षण करना → शुरुआती मांग कुछ सीटों पर केंद्रित होती है, जो एक समान वितरण के पीछे लॉक प्रतीक्षा और रीट्राई स्टॉर्म को छिपा देती है → हॉट सीटों, ओवरलैपिंग समूहों, तत्काल बर्स्ट और धीमी निर्भरताओं का परीक्षण करें।

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

फ़ॉलो-अप 1: जनरल एडमिशन के लिए क्या बदलता है जब केवल टिकट-टियर की मात्रा ओवरसेल नहीं होनी चाहिए?

प्रति-सीट स्थिति को InventoryBucket(event_id, tier_id, available, held, sold, version) से बदलें। एक होल्ड ट्रांजेक्शन में सशर्त रूप से available >= quantity की आवश्यकता होती है, एक बार डिक्रिमेंट होता है, और होल्ड बनता है। एक्सपायरी और कन्फर्मेशन अभी भी hold_id द्वारा गणना को इडेम्पोटेंट रूप से स्थानांतरित करते हैं। अत्यधिक विवादित टियर राइट्स को फैलाने के लिए कई बकेट का उपयोग कर सकता है, लेकिन एक कोटा कंट्रोल प्लेन को बकेट क्षमताओं को आवंटित करना होगा और उनका योग वास्तविक इन्वेंट्री के भीतर रखना होगा। एटॉमिक सीट चयन को हटाने से स्टोरेज सरल हो जाता है; एक्सपायरी और अज्ञात-भुगतान रेस बनी रहती हैं।

फ़ॉलो-अप 2: ऑथराइजेशन का औसत 90 सेकंड है और अतिरिक्त प्रमाणीकरण पाँच मिनट से अधिक हो सकता है। आप लंबे समय तक चलने वाले होल्ड्स को कैसे रोकते हैं?

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

फ़ॉलो-अप 3: सेल के दौरान प्राइमरी राइट क्षेत्र गायब हो जाता है। क्या किसी अन्य क्षेत्र को तुरंत कार्यभार संभाल लेना चाहिए?

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

फ़ॉलो-अप 4: फ्रॉड नियंत्रणों को शुद्धता की निर्भरता बनाए बिना आप निष्पक्षता में सुधार कैसे करते हैं और बॉट्स को कैसे सीमित करते हैं?

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

फ़ॉलो-अप 5: प्रत्येक सीट को मौजूदा वितरित लॉक सेवा (डिस्ट्रिब्यूटेड लॉक सर्विस) से सुरक्षित क्यों नहीं किया जाता?

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