ऑड्स फ़ीड API कैसे काम करता है: स्नैपशॉट से सेटलमेंट तक

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

1. डेटा मॉडल

लगभग हर फ़ीड एक ही पदानुक्रम इस्तेमाल करता है:

• खेल: फ़ुटबॉल, टेनिस, ईस्पोर्ट्स।
• टूर्नामेंट या लीग: Premier League, ATP टोक्यो, League of Legends Worlds।
• इवेंट: एक मैच, शुरुआती समय और प्रतिभागियों के साथ।
• मार्केट: इवेंट के बारे में एक सवाल, जैसे 1X2, 2.5 गोल से ज़्यादा/कम या मैप हैंडीकैप।
• आउटकम: एक जवाब, भाव और स्थिति (सक्रिय, सस्पेंड, सेटल) के साथ।

हर तत्व की एक स्थिर पहचान (ID) होती है। ज़्यादातर इंटीग्रेशन बग नामों को ID मानने से आते हैं: टीमों के नामों की वर्तनी बदलती है, ID नहीं।

2. पहले स्नैपशॉट, फिर डेल्टा

शुरू होने पर क्लाइंट स्नैपशॉट माँगता है: पूरी मौजूदा स्थिति। उसके बाद उसे डेल्टा मिलते हैं, छोटे संदेश जो कहते हैं “यह भाव बदला”, “यह मार्केट सस्पेंड हुआ”, “यह इवेंट शुरू हुआ”।

अच्छे फ़ीड अपने डेल्टा पर नंबर डालते हैं। मसलन, Nocturn Sport अपने फ़ीड को पूरा स्नैपशॉट और संस्करण-क्रमांकित डेल्टा बताता है। अगर क्लाइंट के पास संस्करण N है और उसे N+2 मिलता है, तो वह समझ जाता है कि कोई संदेश खो गया और पुराना भाव दिखाने के बजाय दोबारा लोड करता है। बिना संस्करण वाले फ़ीड क्लाइंट को अंदाज़ा लगाने पर मजबूर करते हैं, और अंदाज़े से ही बुक कल के ऑड्स पेश करने लगती हैं।

3. पुश और पुल

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

4. सस्पेंशन

सस्पेंशन फ़ीड का यह कहना है कि “अभी इस पर दाँव मत लो”। कारणों में गोल, पेनल्टी, सर्विस ब्रेक, मैप का ख़त्म होना, या सप्लायर का अपना डेटा स्रोत खो देना शामिल है। क्लाइंट को सस्पेंशन किसी भी और चीज़ से तेज़ लागू करने होते हैं; गोल के बाद के सेकंडों में स्वीकार किया गया भाव पैसा गँवाने का क्लासिक तरीका है।

प्री-मैच मार्केट किक-ऑफ़ से पहले बंद भी होते हैं। मसलन, Nocturn Sport इन्हें शुरुआत से एक मिनट पहले बंद करता है।

5. दाँव लगाना

अगर API भाव प्रकाशित करने से आगे जाता है, तो दाँव लगाने का एक पैटर्न होता है:

1. क्लाइंट चुनाव, दिखाया गया भाव और दाँव की राशि एक अनोखे रिक्वेस्ट ID के साथ भेजता है।
2. सर्वर जाँचता है कि भाव अब भी मान्य है और मार्केट खुला है।
3. वह स्वीकार करता है, अस्वीकार करता है, या नया भाव देता है।
4. नेटवर्क फ़ेल हो, तो क्लाइंट उसी रिक्वेस्ट ID से दोबारा भेजता है, और सर्वर दूसरा दाँव बनाने के बजाय मूल जवाब लौटाता है।

यह आख़िरी क़दम, idempotency, खिलाड़ी के बैलेंस और ऑपरेटर के खातों दोनों की रक्षा करता है।

6. सेटलमेंट

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

7. लाइव होने से पहले क्या टेस्ट करें

• मैच के बीच कनेक्शन तोड़ें और रिकवरी जाँचें।
• एक डेल्टा ग़लत क्रम में दोबारा चलाएँ और देखें कि क्लाइंट पकड़ता है या नहीं।
• एक ही रिक्वेस्ट ID से वही दाँव दो बार लगाएँ।
• ऐसा एक्युमुलेटर सेटल करें जिसका एक हिस्सा रद्द हो।

जो फ़ीड इन चार टेस्ट में टिक जाए, वह शनिवार की दोपहर के लिए तैयार है।