बैकएंड इंटरव्यू: आप HTTP 413 Content Too Large कॉन्ट्रैक्ट कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और दायरा

एक वीडियो अपलोड CDN, API गेटवे, एप्लिकेशन सर्विस और ऑब्जेक्ट स्टोर से होकर गुजरता है, जिनमें से प्रत्येक का स्वीकृत आकार अलग होता है। 413 Content Too Large रिस्पॉन्स, सीमा खोज (limit discovery), रिज़्यूमेबल अपलोड, Retry-After, एरर बॉडी और मॉनिटरिंग डिज़ाइन करें।

यह एक बैकएंड API विश्वसनीयता (reliability) संबंधी प्रश्न है। परतों (layers) की संख्या और वीडियो का आकार धारणाएं हैं, बारंबारता के दावे नहीं।

इंटरव्यूअर क्या जांच रहा है

• क्या आप स्थायी सीमाओं, अस्थायी क्षमता और बॉडी-सत्यापन विफलता के बीच अंतर करते हैं।
• क्या आप 413 और Retry-After के बीच के संबंध को सटीकता से समझाते हैं।
• क्या आप पूरी बॉडी को पुनः प्रयास करने के बजाय रिज़्यूमेबिलिटी डिज़ाइन करते हैं।
• क्या आप प्रॉक्सी सीमाओं, आइडेम्पोटेंसी और सूचना प्रकटीकरण (information leakage) को संभालते हैं।

पूछने के लिए स्पष्टीकरण प्रश्न

1. किस परत ने 413 उत्सर्जित किया, और क्या इसका दायरा (scope) और request ID संरक्षित हैं?
2. क्या सीमा प्रति अनुरोध, किरायेदार (tenant), ऑब्जेक्ट, समय सीमा, या शेष कोटा पर आधारित है?
3. क्या क्लाइंट चंक्स (chunks) का उपयोग कर सकता है, रिज़्यूम कर सकता है और अपलोड सत्र (upload session) से पूछताछ कर सकता है?
4. क्या सीमा निश्चित कॉन्फ़िगरेशन है या अस्थायी क्षमता अथवा कोटा है?
5. क्या प्राप्त बाइट्स से बिलिंग, लॉक्स या ऑब्जेक्ट मेटाडेटा के साइड इफेक्ट्स उत्पन्न हो सकते हैं?

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

“413 का अर्थ है कि सर्वर उस सामग्री को प्रोसेस करने से मना करता है जो बहुत बड़ी है। एक निश्चित सीमा के लिए क्लाइंट को प्रतीक्षा नहीं करानी चाहिए; एक अस्थायी स्थिति में Retry-After शामिल हो सकता है। एज (edge) को एक स्थिर कोड, request ID और सार्वजनिक प्रतिबंध के साथ शुरुआत में ही अस्वीकार कर देना चाहिए, जबकि एप्लिकेशन अभी भी वास्तविक बाइट्स को मान्य करता है। बड़ी फ़ाइलें एक अपलोड सत्र, चंक्स और एक आइडेम्पोटेंट समापन का उपयोग करती हैं। डिस्कनेक्ट होने के बाद, पुनः भेजने से पहले स्थिति की जांच करें; पुष्टि किए गए चंक्स को कभी भी दोबारा न भेजें। मैं परत, किरायेदार और आकार के आधार पर 413 को मापता हूँ।”

चरण-दर-चरण डिज़ाइन

1. स्तरित सीमाओं को परिभाषित करें

निश्चित अधिकतम सीमाओं, किरायेदार कोटा, ऑब्जेक्ट नीति और रनटाइम क्षमता के स्पष्ट स्वामी होने चाहिए। एक एज Content-Length से अस्वीकार कर सकता है, लेकिन एप्लिकेशन को प्राप्त बाइट्स, डीकंप्रेस किए गए आकार और सामग्री नीति की भी जांच करनी चाहिए। त्रुटि में एक request ID शामिल करें; आंतरिक नोड्स, डिस्क क्षमता या किसी अन्य किरायेदार के डेटा को प्रकट न करें।

2. Retry-After का सही उपयोग करें

RFC 9110 सर्वर को Retry-After उत्पन्न करने की अनुमति देता है जब 413 स्थिति अस्थायी होती है। यह मान HTTP तिथि या विलंब सेकंड हो सकता है। एक निश्चित अधिकतम सीमा के लिए बदले हुए अनुरोध या चंक्स की आवश्यकता होती है, न कि प्रतीक्षा की। किसी ज्ञात कोटा या रखरखाव रिकवरी विंडो के लिए हेडर का उपयोग करें, और क्लाइंट्स से विलंब को सीमित (cap) और मान्य करवाएं।

HTTP/1.1 413 Content Too Large
Retry-After: 120
Content-Type: application/problem+json
X-Request-Id: req-81a

3. त्रुटि को कार्रवाई-योग्य (actionable) बनाएं

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

4. रिज़्यूमेबल अपलोड प्रदान करें

पहले एक अपलोड सत्र बनाएं और उसका ID, समाप्ति समय, चंक-आकार सीमा और पूर्ण हो चुके चंक्स की जानकारी के लिए एक क्वेरी लौटाएं। प्रत्येक चंक में एक डाइजेस्ट और आइडेम्पोटेंसी कुंजी होती है; समापन केवल सत्यापित चंक्स को संदर्भित करता है। 413 पर, क्लाइंट पुष्टि किए गए डेटा को पुनः प्रेषित किए बिना एक नया चंक कम कर सकता है या एक नया सत्र बना सकता है।

5. असंगत परतों को संभालें

गेटवे एप्लिकेशन से पहले 413 लौटा सकता है, जबकि एप्लिकेशन डीकंप्रेशन, कोटा या नीति जांच के बाद अस्वीकार कर सकता है। एक साझा त्रुटि मॉडल यह नहीं मान सकता कि प्रत्येक परत अंतिम सीमा जानती है। सत्र निर्माण के समय वर्तमान बाधाओं को लौटाएं, 413 स्रोतों की निगरानी करें, और किसी एक परत के अस्थायी मान को स्थायी वैश्विक सीमा के रूप में कैश न करें।

6. पुनः प्रयास, बिलिंग और मेट्रिक्स को एक साथ जोड़ें

क्लाइंट पर 413 को वर्गीकृत करें: एक निश्चित सीमा के लिए अनुरोध बदलें, एक अस्थायी सीमा के लिए Retry-After का पालन करें, और एक सत्र विफलता के बाद सत्र स्थिति की जांच करें। समापन के लिए आइडेम्पोटेंसी का उपयोग करें ताकि बिलिंग की नकल न हो, और छोड़े गए सत्रों को समाप्त (expire) करें। सीमा विचलन का पता लगाने के लिए स्रोत परत, किरायेदार, अनुरोध आकार, अपलोड किए गए बाइट्स, Retry-After अनुपालन, चंक पुनः प्रेषण और अंतिम रिकवरी को ट्रैक करें।

मॉडल उच्च-गुणवत्ता वाला उत्तर

“मैं सबसे पहले उत्सर्जक परत और सीमा प्रकार की पहचान करता हूँ। एक निश्चित अधिकतम सीमा सार्वजनिक प्रतिबंध या चंक प्रविष्टि बिंदु के साथ 413 लौटाती है; केवल अस्थायी कोटा या क्षमता Retry-After लौटाती है। बड़ी फ़ाइलें डाइजेस्ट और आइडेम्पोटेंसी के साथ सत्रों और चंक्स का उपयोग करती हैं, और एक डिस्कनेक्ट किया गया क्लाइंट पुष्टि किए गए चंक्स की जांच करता है। एज शुरुआत में ही अस्वीकार कर देता है, जबकि एप्लिकेशन वास्तविक और डीकंप्रेस किए गए बाइट्स की जांच करता है। एरर बॉडी केवल एक स्थिर कोड, request ID और अगला कदम उजागर करती है। मैं स्रोत, आकार वितरण, प्रतीक्षा अनुपालन, डुप्लिकेट समापन और रिकवरी दर को मापता हूँ।”

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

• प्रत्येक 413 में Retry-After जोड़ना → निश्चित सीमाएं व्यर्थ प्रतीक्षा का कारण बनती हैं → समय का उपयोग केवल अस्थायी स्थितियों के लिए करें।
• एक क्लाइंट सीमा को हार्ड-कोड करना → परतें विचलित होती हैं → सत्र प्रतिबंध लौटाएं और स्रोत की निगरानी करें।
• पूरी बॉडी को दोबारा भेजना → बैंडविड्थ और साइड इफेक्ट्स कई गुना बढ़ जाते हैं → चंक्स, प्रश्नों और आइडेम्पोटेंट समापन का उपयोग करें।
• केवल Content-Length की जांच करना → डीकंप्रेस किए गए या वास्तविक बाइट्स सीमाओं से अधिक हो सकते हैं → इनजेशन के दौरान और बाद में मान्य करें।
• आंतरिक सीमाओं को उजागर करना → टोपोलॉजी और क्षमता लीक हो जाती है → एक स्थिर कोड और request ID लौटाएं।

अनुवर्ती प्रश्न और उत्तर

जब 413 में Retry-After न हो तो क्लाइंट को क्या करना चाहिए?

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

क्या होगा यदि कोई चंक भी किसी एक परत की सीमा से अधिक हो जाए?

सत्र निर्माण के समय वर्तमान में अनुमत सीमा लौटाएं और सबसे छोटी प्रभावी सीमा से बड़ा चंक न चुनें। यदि नीति बदलती है, तो पुराने चंक्स को दोबारा सबमिट करने के बजाय पुष्टि किए गए चंक्स को सुरक्षित रखें और नए सत्र मापदंडों के साथ जारी रखें।

गेटवे ने 413 लौटाया लेकिन एप्लिकेशन में कोई रिकॉर्ड नहीं है। आप इसे कैसे डीबग करेंगे?

एज, गेटवे और एप्लिकेशन में request IDs, प्राप्त बाइट्स और प्रतिक्रिया स्रोत की तुलना करें। यदि एप्लिकेशन में कोई रिकॉर्ड नहीं है, तो पहले गेटवे सीमाओं, रूटिंग और बॉडी फॉरवर्डिंग का निरीक्षण करें; गायब एप्लिकेशन लॉग किसी एप्लिकेशन अस्वीकृति को सिद्ध नहीं करते हैं।