प्रॉम्प्ट और दायरा
सर्विस में एक बड़ी orders टेबल, कई चाइल्ड टेबल्स, पब्लिक URLs, इवेंट पेलोड्स और रेप्लिकाएं हैं। PostgreSQL 18 टाइमस्टैम्प-ऑर्डर्ड UUIDs के लिए एक नेटिव uuidv7() जनरेटर प्रदान करता है। मौजूदा UUIDv4 कॉन्ट्रैक्ट को बनाए रखते हुए और टेबल रीराइट या लंबे ब्लॉकिंग लॉक से बचते हुए नए रिकॉर्ड्स को UUIDv7 की ओर ले जाएं।
यह एक backend प्रश्न है क्योंकि मुख्य कौशल APIs, स्टोरेज और एसिंक्रोनस कंज्यूमर्स के बीच एक ऑनलाइन आइडेंटिटी और स्कीमा माइग्रेशन है।
इंटरव्यूअर्स क्या आकलन करते हैं
पहला, क्या आप आइडेंटिफायर फॉर्मेट और कालानुक्रमिक सत्य (chronological truth) के बीच अंतर कर सकते हैं? UUIDv7 में टाइम ऑर्डरिंग एम्बेडेड होती है, लेकिन यह एक स्ट्रिक्ट ग्लोबल कमिट सीक्वेंस नहीं है और इसे एक स्पष्ट बिज़नेस टाइमस्टैम्प की जगह नहीं लेनी चाहिए।
दूसरा, क्या आप पब्लिक आइडेंटिटी को सुरक्षित रख सकते हैं? मौजूदा URLs, कैशे, इडेम्पोटेन्सी कीज़, इवेंट्स और फॉरेन कीज़ को माइग्रेशन के दौरान रिज़ॉल्व होना जारी रहना चाहिए।
तीसरा, क्या आप एक स्पष्ट सोर्स ऑफ ट्रुथ के साथ ड्यूल-रीड और ड्यूल-राइट फेज़ डिज़ाइन कर सकते हैं?
चौथा, क्या आप राइट एम्प्लीफिकेशन या रेप्लिकेशन लैग पैदा किए बिना रेप्लिकाओं और रीजन्स में सुरक्षित रूप से बैकफिल कर सकते हैं?
पांचवां, क्या आप यह मानने के बजाय कि UUIDv7 हर वर्कलोड के लिए अपने आप तेज़ है, लोकैलिटी और लेटेंसी को वैलिडेट कर सकते हैं?
पहले स्पष्ट करने योग्य प्रश्न
- क्या UUID को बाहरी रूप से एक्सपोज़ किया गया है, प्राइमरी की के रूप में उपयोग किया गया है, या दोनों?
- क्या क्लाइंट्स एक नया आइडेंटिफायर स्वीकार कर सकते हैं, या पुराने UUID को ही कैनोनिकल रहना चाहिए?
- कितनी चाइल्ड टेबल्स, इंडेक्स, इवेंट्स और सर्च डॉक्यूमेंट्स इस की को रेफरेंस करते हैं?
- प्रत्येक राइटर और रेप्लिका पर कौन से PostgreSQL वर्जन्स और एक्सटेंशन मौजूद हैं?
- राइट रेट, रेप्लिकेशन-लैग SLO और रोलबैक की समय सीमा क्या है?
- क्या ऑर्डरिंग की आवश्यकता पेजिनेशन, ऑडिट डिस्प्ले के लिए है, या केवल इंडेक्स लोकैलिटी के लिए?
30-सेकंड उत्तर फ्रेमवर्क
“मैं UUIDv4 को स्थिर पब्लिक आइडेंटिफायर के रूप में रखूंगा, एक UUIDv7 सरोगेट या मैपिंग कॉलम जोड़ूंगा, और किसी भी बैकफिल से पहले ड्यूल राइट्स रोल आउट करूंगा। जब तक मैपिंग पूरी नहीं हो जाती, रीड्स किसी भी की को स्वीकार करते हैं; चाइल्ड रेफरेंस और इवेंट्स कम्पैटिबल रहते हैं। लैग और लॉक मॉनिटरिंग के साथ बाउंडेड प्राइमरी-की रेंज में बैकफिल करें, फिर पैरिटी चेक के बाद इंटरनल इंडेक्स और क्वेरी पाथ को स्विच करें। UUIDv7 लोकैलिटी और समय-उन्मुख स्कैन में मदद करता है, लेकिन टाइमस्टैम्प स्पष्ट बने रहते हैं। जब तक सभी कंज्यूमर्स प्रमाणित नहीं हो जाते, रोलबैक एक फीचर-फ्लैग रिवर्सल है।”
चरण-दर-चरण उत्तर
चरण 1: कम्पैटिबिलिटी शेप चुनें
किसी मौजूदा UUID के अर्थ को चुपचाप न बदलें। order_id_v4 को बाहरी कॉन्ट्रैक्ट के रूप में रखें और order_id_v7 के साथ एक यूनिक कंस्ट्रेंट जोड़ें, या एक ड्यूरेबल मैपिंग के साथ एक अलग इंटरनल की पेश करें। तय करें कि प्रत्येक फेज़ के दौरान चाइल्ड टेबल्स और इवेंट्स किस की का उपयोग करते हैं।
ALTER TABLE orders ADD COLUMN order_id_v7 uuid;
CREATE UNIQUE INDEX CONCURRENTLY orders_order_id_v7_uq
ON orders(order_id_v7) WHERE order_id_v7 IS NOT NULL;uuidv7() का उपयोग केवल उन PostgreSQL वर्जन्स पर करें जो इसे प्रदान करते हैं; अन्यथा पाथ को सक्षम करने से पहले लगातार एक समान जनरेटर डिप्लॉय करें।
चरण 2: पहले राइट्स को रोल आउट करें
नए राइट्स एक ट्रांजैक्शन में दोनों आइडेंटिफायर्स जनरेट करते हैं और मैपिंग रिकॉर्ड करते हैं। मौजूदा राइट्स जो नए कॉलम को पॉप्युलेट नहीं कर सकते, वे मान्य रहते हैं। रिट्रीज़ को इडेम्पोटेंट बनाएं ताकि बार-बार कमांड देने से दो मैपिंग न बनें।
चरण 3: ड्यूल-रीड रिज़ॉल्यूशन जोड़ें
API लुकअप किसी भी आइडेंटिफायर को स्वीकार करता है, एक कैनोनिकल ऑर्डर में रिज़ॉल्व करता है, और पुराने रिस्पॉन्स में लेगेसी ID प्रदान करता है। नए एंडपॉइंट्स वर्जन्ड कॉन्ट्रैक्ट्स के पीछे UUIDv7 को एक्सपोज़ कर सकते हैं। कैशे कीज़ में रिज़ॉल्व की गई कैनोनिकल आइडेंटिटी शामिल होनी चाहिए ताकि दोनों रूप अलग न हों।
चरण 4: सीमित बैचों में बैकफिल करें
एक स्थिर कर्सर, छोटे ट्रांजैक्शन्स का उपयोग करके पंक्तियों को बैकफिल करें, और जब रेप्लिकेशन लैग, लॉक वेट्स, या राइट लेटेंसी किसी सीमा को पार कर जाए तो रुकें। पर्याप्त डेटा मौजूद होने के बाद, जहां समर्थित हो वहां समवर्ती ऑपरेशन्स (concurrent operations) का उपयोग करके नए कॉलम को इंडेक्स करें। चाइल्ड टेबल्स को तब तक अपडेट न करें जब तक कि पेरेंट मैपिंग ड्यूरेबल न हो।
चरण 5: रेफरेंस और इवेंट्स को माइग्रेट करें
ओवरलैप के दौरान चाइल्ड फॉरेन कीज़ और इवेंट स्कीमा को कम्पैटिबल रखें। v7 फ़ील्ड्स को वैकल्पिक रूप में जोड़ें, दोनों वैल्यूज पब्लिश करें, और v7 को अनिवार्य बनाने से पहले कंज्यूमर्स को अपडेट करें। कंस्ट्रेंट्स को स्विच करने से पहले छूटी हुई मैपिंग और डुप्लिकेट मैपिंग का समाधान (reconcile) करें।
चरण 6: इंटरनल एक्सेस पाथ्स को स्विच करें
पैरिटी चेक के बाद, इंटरनल जॉइन्स और पेजिनेशन को UUIDv7 पर रूट करें जहाँ लोकैलिटी या समय-उन्मुख स्कैन मायने रखते हैं। बिज़नेस ऑर्डरिंग के लिए स्पष्ट created_at रखें और टाई-ब्रेकर का उपयोग करें; एप्लिकेशन स्तर पर UUIDv7 ऑर्डरिंग अनुमानित (approximate) होती है।
चरण 7: वैलिडेट और ऑब्ज़र्व करें
इंडेक्स साइज़, पेज स्प्लिट्स, कैशे व्यवहार, इंसर्ट लेटेंसी, रेंज-स्कैन लेटेंसी, रेप्लिकेशन लैग और एरर रेट्स की तुलना एक समान वर्कलोड से करें। जांचें कि v4 और v7 लुकअप एक ही पंक्ति लौटाते हैं और इवेंट कंज्यूमर्स इडेम्पोटेंट बने रहते हैं।
चरण 8: केवल रोलबैक विंडो के बाद ही रिटायर करें
मैपिंग, पुराने इंडेक्स और ड्यूल-रीड पाथ को तब तक बनाए रखें जब तक कि हर क्लाइंट, रीप्ले टूल, एक्सपोर्ट और रेप्लिका माइग्रेशन विंडो को पार न कर ले। एक स्पष्ट रोलबैक योजना के साथ अलग-अलग डिप्लॉयमेंट में पुराने कंस्ट्रेंट्स को हटाएं।
मॉडल उत्तर
“मैं पब्लिक UUID कॉन्ट्रैक्ट को सीधे इन-प्लेस रीराइट नहीं करूंगा। मैं एक UUIDv7 कॉलम और यूनिक मैपिंग जोड़ूंगा, ड्यूल राइट्स डिप्लॉय करूंगा, फिर ड्यूल रीड्स जो किसी भी रूप को एक ही ऑर्डर में रिज़ॉल्व करते हैं। लॉक्स, रेप्लिकेशन लैग और राइट लेटेंसी पर नज़र रखते हुए सीमित ट्रांजैक्शन्स में बैकफिल करूंगा। चाइल्ड रेफरेंस और इवेंट्स दोनों IDs तब तक ले जाते हैं जब तक कि प्रत्येक कंज्यूमर v7 को समझ न ले। पैरिटी और लोकैलिटी मापों के बाद, बिज़नेस ऑर्डरिंग फ़ील्ड के रूप में created_at को रखते हुए इंटरनल जॉइन्स और पेजिनेशन को स्विच करूंगा। फीचर फ्लैग रीड्स और राइट्स को तब तक रिवर्स कर सकता है जब तक कि पुराना पाथ रिटायर न हो जाए।”
सामान्य गलतियाँ
- पब्लिक UUIDs को तुरंत बदलना → लिंक्स और इवेंट्स टूट जाते हैं → एक कैनोनिकल कॉन्ट्रैक्ट और मैपिंग को सुरक्षित रखें।
- यह मान लेना कि UUIDv7 एक स्ट्रिक्ट टाइम ऑर्डर है → पेजिनेशन रिकॉर्ड्स को छोड़ देता है या रीऑर्डर कर देता है → स्पष्ट टाइमस्टैम्प और टाई-ब्रेकर्स का उपयोग करें।
- एक विशाल ट्रांजैक्शन में बैकफिल करना → लॉक्स और रेप्लिकेशन लैग बढ़ जाते हैं → सीमित बैचों (bounded batches) का उपयोग करें।
- मैपिंग मौजूद होने से पहले फॉरेन की जोड़ना → ओवरलैप के दौरान राइट्स विफल हो जाते हैं → पेरेंट, चिल्ड्रन, फिर कंस्ट्रेंट्स को माइग्रेट करें।
- मिश्रित असमर्थित वर्जन्स पर IDs जनरेट करना → सिमेंटिक्स अलग हो जाते हैं → वर्जन्स को पिन करें या एक समान जनरेटर का उपयोग करें।
- रिट्रीज़ को अनदेखा करना → डुप्लिकेट मैपिंग दिखाई देती हैं → ड्यूल राइट्स को इडेम्पोटेंट बनाएं।
- v4 को बहुत जल्दी ड्रॉप करना → पुराने एक्सपोर्ट्स और रीप्ले विफल हो जाते हैं → रोलबैक विंडो तक प्रतीक्षा करें।
फॉलो-अप प्रश्न
फॉलो-अप 1: क्या UUIDv7 created_at का विकल्प है?
नहीं। यह लोकैलिटी में सुधार कर सकता है और टाइमस्टैम्प-उन्मुख बिट्स प्रदान कर सकता है, लेकिन बिज़नेस ऑर्डरिंग के लिए एक स्पष्ट टाइमस्टैम्प और डिटरमिनिस्टिक टाई-ब्रेकर की आवश्यकता होती है।
फॉलो-अप 2: क्या v4 और v7 एक UUID कॉलम शेयर कर सकते हैं?
हाँ, UUID प्रकार दोनों फॉर्मेट्स को रख सकता है, लेकिन माइग्रेशन मेटाडेटा, बाहरी कॉन्ट्रैक्ट्स और ऑर्डरिंग सिमेंटिक्स के लिए अभी भी एक स्पष्ट योजना की आवश्यकता है।
फॉलो-अप 3: राइट्स स्विच करने से पहले ड्यूल-रीड क्यों?
यह पुराने और नए रिकॉर्ड्स को लगातार रिज़ॉल्व होने देता है जबकि बैकफिल और कंज्यूमर रोलआउट अधूरा होता है।
फॉलो-अप 4: आप बैकफिल को कैसे थ्रॉटल करते हैं?
सीमित ट्रांजैक्शन्स का उपयोग करें और रेप्लिकेशन लैग, लॉक वेट्स, CPU, या राइट-लेटेंसी थ्रेशोल्ड पर रुकें; एक ड्यूरेबल कर्सर से फिर से शुरू करें।
फॉलो-अप 5: इवेंट्स में क्या होना चाहिए?
ओवरलैप के दौरान, दोनों IDs या एक स्थिर मैपिंग रेफरेंस पब्लिश करें, स्कीमा का वर्ज़न बनाएं, और v7 को अनिवार्य बनाने से पहले कंज्यूमर्स को अपडेट करें।
फॉलो-अप 6: पुराने कॉलम को कब हटाया जा सकता है?
क्लाइंट्स, एक्सपोर्ट्स, रीप्ले, रेप्लिकाओं और रोलबैक चेक्स द्वारा सहमत विंडो को पास करने के बाद ही; अलग-अलग रिवर्सिबल डिप्लॉयमेंट में कंस्ट्रेंट्स और इंडेक्स को हटाएं।