बैकएंड इंटरव्यू: आपको REST या gRPC कब चुनना चाहिए?

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

एक प्लेटफॉर्म की तीन API सीमाएं (boundaries) हैं। ब्राउज़र, मोबाइल ऐप्स और बाहरी पार्टनर्स पहली सीमा का उपयोग करते हैं, इसलिए इसे स्वतंत्र रूप से एकीकृत (integrate), डीबग और विकसित (evolve) करना आसान होना चाहिए। दूसरा एक नियंत्रित डेटा-सेंटर परिवेश में सर्विस-टू-सर्विस ट्रैफ़िक है। यह 20,000 कॉल्स प्रति सेकंड के चरम पर पहुंचता है और इसे साधारण रिक्वेस्ट-रिस्पॉन्स कॉल्स और सर्वर स्ट्रीम दोनों की आवश्यकता होती है। तीसरा बाहरी प्रणालियों से वेबहुक कॉलबैक्स प्राप्त करता है।

20,000 कॉल्स प्रति सेकंड का आंकड़ा एक इंटरव्यू का अनुमान है, कोई सार्वभौमिक प्रदर्शन सीमा नहीं। प्रत्येक सीमा के लिए JSON के साथ REST-शैली HTTP, नेटिव gRPC, या एक उचित संयोजन चुनें, फिर माइग्रेशन और वैलिडेशन की व्याख्या करें। REST एक आर्किटेक्चरल शैली है और यह JSON या HTTP/1.1 से बंधी नहीं है। “REST/HTTP+JSON” केवल इस प्रॉम्प्ट में तुलना किए जा रहे सामान्य कार्यान्वयन को निर्धारित करता है। gRPC कोई ऐसा स्विच नहीं है जो किसी ऑपरेशन को स्वचालित रूप से तेज़, इडेम्पोटेंट या विश्वसनीय बना दे।

यह एक बैकएंड प्रश्न है क्योंकि इसका मूल सर्विस इंटरफ़ेस, प्रोटोकॉल सेमेंटिक्स, क्लाइंट कॉन्ट्रैक्ट्स और प्रोडक्शन गवर्नेंस है। यह संपूर्ण व्यावसायिक प्रणाली की मांग नहीं करता है, और केवल “gRPC तेज़ है; REST अधिक कम्पैटिबल है” जैसी याद की गई तालिका पर्याप्त नहीं है।

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

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

दूसरा संकेत एब्स्ट्रैक्शन को कार्यान्वयन से अलग करना है। REST संसाधनों, HTTP मेथड्स, स्टेटस कोड और कैशिंग सेमेंटिक्स का उपयोग करता है, और यह HTTP/2 या HTTP/3 पर चल सकता है। gRPC सेवाओं और मेथड्स पर केंद्रित है, अपने डिफ़ॉल्ट इंटरफ़ेस और संदेश परिभाषा के रूप में Protocol Buffers का उपयोग करता है, और यूनरी, क्लाइंट-स्ट्रीमिंग, सर्वर-स्ट्रीमिंग और बाईडायरेक्शनल-स्ट्रीमिंग मेथड्स प्रदान करता है। “REST केवल HTTP/1.1 का उपयोग करता है” और “REST स्ट्रीम नहीं कर सकता” दोनों ही त्रुटिपूर्ण शॉर्टकट हैं।

तीसरा संकेत कॉन्ट्रैक्ट और विफलता मॉडल को पूरा करना है। OpenAPI एक HTTP API को मशीन-पठनीय कॉन्ट्रैक्ट और कोड जनरेशन प्रदान कर सकता है। Protobuf बाइनरी कम्पैटिबिलिटी एप्लिकेशन कम्पैटिबिलिटी की गारंटी नहीं देती है। दोनों में से किसी भी विकल्प के लिए डेडलाइन्स, कैंसलेशन, इडेम्पोटेंसी, पुनः प्रयास योग्य त्रुटि नियम (retryable-error rules), प्रमाणीकरण (authentication), प्राधिकरण (authorization), वर्ज़न इवोल्यूशन और अवलोकनीय (observable) रिक्वेस्ट पहचान की आवश्यकता होती है।

अंत में, मजबूत उम्मीदवार साक्ष्य मांगते हैं। वे प्रतिनिधि पेलोड, समवर्तीता (concurrency), कम्प्रेशन, कनेक्शन व्यवहार और विफलताओं को बेंचमार्क करते हैं, फिर टेल लेटेंसी और त्रुटियों को मापते हुए परिणाम का कैनरी परीक्षण करते हैं। केवल “बाइनरी तेज़ है” द्वारा उचित ठहराया गया प्लेटफ़ॉर्म माइग्रेशन पुनरुत्पादनीय इंजीनियरिंग (reproducible engineering) नहीं है।

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

• क्लाइंट्स और अपग्रेड्स को कौन नियंत्रित करता है? एक संगठन के भीतर की सेवाएं जनरेट किए गए क्लाइंट रिलीज़ को समन्वित कर सकती हैं। जिन पार्टनर्स को अपग्रेड करने के लिए बाध्य नहीं किया जा सकता, उन्हें एक स्थिर सीमा की आवश्यकता होती है जिसे स्वतंत्र रूप से उपयोग करना आसान हो।
• क्या इंटरैक्शन यूनरी, स्ट्रीमिंग, या एसिंक्रोनस नोटिफिकेशन है? साधारण CRUD को gRPC से स्वचालित रूप से लाभ नहीं होता है। लंबे समय तक चलने वाले कनेक्शन पर एक क्रमित स्ट्रीम नेटिव gRPC के अनुकूल हो सकती है। एक थर्ड-पार्टी वेबहुक किसी अन्य द्वारा शुरू किया जाता है और आमतौर पर उस पार्टी के प्रकाशित HTTP कॉन्ट्रैक्ट का पालन करना चाहिए।
• क्या किसी ब्राउज़र को सेवा को सीधे कॉल करना होगा? ब्राउज़र नेटिव gRPC द्वारा आवश्यक सभी HTTP/2 नियंत्रण सीधे प्रदान नहीं कर सकते हैं। gRPC-Web, JSON ट्रांसकोडिंग, या एक BFF एक ऐसी परत जोड़ता है जो डीबगिंग, स्ट्रीमिंग क्षमताओं और संचालन को बदल देती है।
• वास्तविक प्रदर्शन समस्या क्या है? सीरियलाइज़ेशन बदलने से डेटाबेस की अड़चन (bottleneck), डाउनस्ट्रीम फ़ैन-आउट, या अनबाउंडेड क्वेरी दूर नहीं होगी। पेलोड आकार, QPS, समवर्तीता, p95/p99, CPU और नेटवर्क बजट के बारे में पूछें।
• वर्तमान गेटवे और ऑब्जर्वेबिलिटी स्टैक क्या सपोर्ट करते हैं? gRPC स्टेटस, स्ट्रीम्स, हेल्थ चेक और एंड-टू-एंड ट्रेस कोरिलेशन के लिए प्रॉक्सी सपोर्ट सीधे रोलआउट जोखिम को बदल देता है।
• इंटरफ़ेस को कैसे विकसित होना चाहिए? पब्लिक APIs को एक कम्पैटिबिलिटी नीति की आवश्यकता होती है। इंटरनल Protobuf को फ़ील्ड-नंबर और मिश्रित-वर्ज़न नियमों की आवश्यकता होती है। क्रॉस-वर्ज़न परीक्षणों के बिना, एक स्ट्रॉन्गली टाइप्ड कॉन्ट्रैक्ट भी रोलिंग डिप्लॉयमेंट के दौरान विफल हो सकता है।

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

“मैं प्रत्येक प्लेटफ़ॉर्म-व्यापी विकल्प चुनने के बजाय प्रत्येक कंज्यूमर सीमा के अनुसार चयन करूंगा। ब्राउज़र, मोबाइल और पार्टनर API की शुरुआत JSON के साथ REST-शैली HTTP के रूप में होती है, जो OpenAPI, HTTP सेमेंटिक्स और एक कम्पैटिबिलिटी नीति द्वारा शासित होती है। थर्ड-पार्टी वेबहुक भी अपने पब्लिक HTTP कॉन्ट्रैक्ट का पालन करता है। 20,000 कॉल्स प्रति सेकंड वाले नियंत्रित आंतरिक पथ के लिए, मैं नेटिव gRPC चुनूंगा यदि प्रतिनिधि बेंचमार्क दिखाते हैं कि सीरियलाइज़ेशन या कनेक्शन लागत मायने रखती है और सर्वर स्ट्रीम एक वास्तविक आवश्यकता है। जनरेट किए गए क्लाइंट्स डेडलाइन सेट करने, कैंसलेशन प्रोपेगेट करने, केवल सुरक्षित ऑपरेशन्स को पुनः प्रयास करने और फ़ील्ड कम्पैटिबिलिटी बनाए रखने की आवश्यकता को समाप्त नहीं करते हैं। एज पर, JSON ट्रांसकोडिंग या एक थिन गेटवे एक डोमेन कार्यान्वयन को साझा कर सकता है। रोलआउट से पहले, मैं वास्तविक पेलोड के साथ एंड-टू-एंड p99, CPU, बाइट्स और विफलता पुनर्प्राप्ति की तुलना करूंगा, फिर कॉलर द्वारा माइग्रेट करूंगा। प्रोटोकॉल प्रमाणीकरण, इडेम्पोटेंसी या ऑब्जर्वेबिलिटी का स्थान नहीं लेता है।”

चरण-दर-चरण गहन विश्लेषण

चरण 1: प्रत्येक सीमा का अलग-अलग निर्णय लें

पब्लिक सीमा के लिए JSON के साथ REST-शैली HTTP का उपयोग करें। रिसोर्स URIs, मेथड्स, स्टेटस कोड, कंडीशनल रिक्वेस्ट्स और कैशिंग को ब्राउज़र, CDNs, कमांड-लाइन टूल्स और पार्टनर्स द्वारा व्यापक रूप से समझा जाता है। OpenAPI डॉक्यूमेंटेशन और जनरेट किए गए SDKs के लिए कॉन्ट्रैक्ट स्रोत हो सकता है, इसलिए REST को “अनटाइप्ड और हाथ से लिखा गया” बताना अनुचित है। इसकी लागत यह है कि टीम को अपने एरर मॉडल, पेजिनेशन, ओपन एनम्स (enums) और स्पेसिफिकेशन ड्रिफ्ट को सक्रिय रूप से प्रबंधित करना होगा।

इंटरनल सीमा के लिए gRPC केवल दो शर्तों के पूरा होने के बाद चुनें: कॉलर्स और सर्वर जनरेट किए गए कोड और रनटाइम इन्फ्रास्ट्रक्चर को मानकीकृत कर सकते हैं, और एक प्रतिनिधि बेंचमार्क प्रॉक्सी, डीबगिंग और मिश्रित-वर्ज़न जटिलता की भरपाई के लिए पर्याप्त लाभ दिखाता है। इस प्रॉम्प्ट में सर्वर-स्ट्रीमिंग की एक वास्तविक आवश्यकता भी है। gRPC के स्ट्रीमिंग मेथड्स और प्रति-कॉल मेटाडेटा, स्टेटस और डेडलाइन इसके लिए एक सुसंगत मॉडल बनाते हैं। केवल 20,000-QPS की संख्या ही निर्णय नहीं लेती है।

थर्ड-पार्टी कॉलबैक के लिए HTTP वेबहुक का उपयोग करें। बाहरी प्रेषक प्रोटोकॉल को नियंत्रित करता है, और सार्वजनिक रिसीवर को TLS, हस्ताक्षर सत्यापन (signature verification), त्वरित पावती (quick acknowledgment) और एसिंक्रोनस प्रोसेसिंग की आवश्यकता होती है। रिसीवर को gRPC से बदलने पर HTTP POST रिक्वेस्ट भेजने वाला पार्टनर इसे कॉल करने में सक्षम नहीं हो जाएगा। यदि आंतरिक प्रोसेसिंग पथ gRPC का उपयोग करता है, तो वेबहुक एडेप्टर उस पथ को इनवोक करने से पहले इवेंट को सत्यापित और सुरक्षित (persist) करता है।

चरण 2: निष्पादन योग्य कॉन्ट्रैक्ट्स लिखें

पब्लिक रीड इंटरफ़ेस रिसोर्स और HTTP सेमेंटिक्स का उपयोग करता है:

GET /v1/orders/ord_123
If-None-Match: "order-v7"

200 OK
ETag: "order-v7"
Content-Type: application/json

आंतरिक इंटरफ़ेस क्रियाओं और संदेशों को परिभाषित करता है:

service OrderService {
  rpc GetOrder(GetOrderRequest) returns (Order);
  rpc WatchOrder(WatchOrderRequest) returns (stream OrderEvent);
}

message GetOrderRequest {
  string order_id = 1;
}

दोनों कॉन्ट्रैक्ट्स को प्रमाणीकरण, प्राधिकरण, त्रुटियों, पेजिनेशन या स्ट्रीम-समाप्ति नियमों, आकार सीमाओं और ऑडिट फ़ील्ड की आवश्यकता होती है। एक gRPC मेथड का नाम नेटवर्क लागत को छिपा सकता है, लेकिन कॉलर्स को अभी भी इसे लेटेंसी, टाइमआउट और आंशिक विफलता वाले रिमोट ऑपरेशन के रूप में मानना चाहिए। REST POST भी स्वचालित रूप से इडेम्पोटेंट नहीं होता है; निर्माण कार्यों (create operations) के लिए एक स्थिर इडेम्पोटेंसी कुंजी या व्यावसायिक विशिष्टता बाधा (uniqueness constraint) की आवश्यकता होती है।

चरण 3: विफलता सेमेंटिक्स डिज़ाइन करें

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

पुनः प्रयास (retry) के निर्णय व्यावसायिक सेमेंटिक्स से आते हैं। HTTP GET, HEAD, PUT और DELETE में विनिर्देश में सुरक्षित या इडेम्पोटेंट गुण होते हैं, लेकिन कार्यान्वयन को उन मेथड सेमेंटिक्स का सम्मान करना चाहिए। POST को केवल तभी पुनः प्रयास करना सुरक्षित है जब कोई इडेम्पोटेंसी कुंजी या समकक्ष तंत्र परिणाम को सुरक्षित बनाता है। gRPC मेथड नाम को कोई स्वचालित इडेम्पोटेंसी प्राप्त नहीं होती है; कॉन्ट्रैक्ट को पुनः प्रयास योग्य स्टेटस और ऑपरेशन्स की पहचान करनी चाहिए। दोनों दृष्टिकोणों में प्रयास सीमा (attempt caps), शेष-डेडलाइन जांच, और गेटवे, SDK और एप्लिकेशन में पुनः प्रयासों के ढेर होने से सुरक्षा की आवश्यकता होती है।

एक स्ट्रीमिंग RPC धीमे-कंज्यूमर हैंडलिंग, बैकप्रेशर, प्रति-संदेश सीमा, रिज्यूम स्थिति और डुप्लिकेट इवेंट्स जोड़ता है। यदि कंज्यूमर्स को कर्सर से फिर से शुरू करना है, तो इवेंट्स को स्थिर IDs या अनुक्रम संख्याओं (sequence numbers) की आवश्यकता होती है। केवल एक स्ट्रीम को फिर से खोलना यह साबित नहीं कर सकता कि कोई अंतराल (gaps) या डुप्लिकेट नहीं हैं।

चरण 4: कॉन्ट्रैक्ट्स को रोलिंग इवोल्यूशन में सुरक्षित बनाएं

REST/JSON कम्पैटिबिलिटी में संरचना और सेमेंटिक्स शामिल हैं। रिस्पॉन्स फ़ील्ड जोड़ना केवल तभी सुरक्षित है जब क्लाइंट्स अज्ञात फ़ील्ड्स को सहन करते हैं। डिफ़ॉल्ट पेजिनेशन, क्रम या एनम अर्थ बदलने से JSON पार्स करने योग्य रह सकता है लेकिन एप्लिकेशन टूट सकता है। OpenAPI डिफ्स (diffs), अंतिम पब्लिक SDK, रिकॉर्डेड-रिक्वेस्ट रीप्ले और एंड-टू-एंड असर्शन्स के साथ रिलीज़ को नियंत्रित करें।

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

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

चरण 5: प्रोडक्शन-आकार के साक्ष्य को माइग्रेशन तय करने दें

वास्तविक पेलोड वितरण और मेथड मिश्रण का उपयोग करें, न कि ऐसे माइक्रोबेंचमार्क का जो एक छोटे ऑब्जेक्ट को सीरियलाइज़ करता है। समान डोमेन लॉजिक के विरुद्ध, एंड-टू-एंड थ्रूपुट, p50/p95/p99, क्लाइंट और सर्वर CPU, ट्रांसफ़र किए गए बाइट्स, कनेक्शन्स और मेमोरी को मापें। यूनरी कॉल्स, छोटे और बड़े संदेश, कम्प्रेशन, सर्वर स्ट्रीम्स, धीमे कंज्यूमर्स और क्रॉस-ज़ोन ट्रैफ़िक को कवर करें। डेटाबेस और डाउनस्ट्रीम कार्य को समान रखें ताकि प्रोटोकॉल के प्रभाव को अलग किया जा सके।

डुअल-स्टैक मोड में एक कम जोखिम वाले आंतरिक मेथड को चलाएं और कॉलर द्वारा कैनरी परीक्षण करें। व्यावसायिक परिणामों, त्रुटि वर्गीकरण, डेडलाइन समाप्त होने की घटनाओं, कैंसलेशन के बाद जारी रहे कार्य, पुनः प्रयास प्रवर्धन (retry amplification) और ट्रेस पूर्णता की तुलना करें। लिखित लाभ और विश्वसनीयता सीमाओं को पूरा करने के बाद ही विस्तार करें। जब लाभ नगण्य हो तो HTTP API को बनाए रखना एक मान्य परिणाम है।

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

“मैं पूरे प्लेटफॉर्म को REST या gRPC का लेबल नहीं दूंगा। मैं इससे शुरुआत करूंगा कि प्रत्येक सीमा को कौन कॉल करता है, अपग्रेड्स को कौन नियंत्रित करता है, और कम्युनिकेशन पैटर्न क्या है।

ब्राउज़र, मोबाइल ऐप्स और पार्टनर्स के लिए, मैं JSON के साथ REST-शैली HTTP का उपयोग करूंगा। यह व्यापक HTTP इकोसिस्टम के साथ काम करता है, जबकि OpenAPI एक मशीन-पठनीय कॉन्ट्रैक्ट, SDK जनरेशन और कम्पैटिबिलिटी जांच की आपूर्ति करता है। थर्ड-पार्टी वेबहुक एक HTTP POST बना रहता है क्योंकि प्रेषक का प्रोटोकॉल एक बाहरी बाधा है। इनग्रेस हस्ताक्षर की पुष्टि करता है, इवेंट ID द्वारा डिडुप्लीकेट करता है, इवेंट को सुरक्षित करता है, और इसे एसिंक्रोनस रूप से प्रोसेस करता है।

आंतरिक सीमा में 20,000 कॉल्स प्रति सेकंड और एक सर्वर स्ट्रीम है। मैं प्रोडक्शन-आकार के पेलोड को बेंचमार्क करूंगा। यदि सभी कॉलर्स जनरेट किए गए क्लाइंट्स का उपयोग कर सकते हैं, प्रॉक्सीज़, लोड बैलेंसर्स और मॉनिटरिंग gRPC को समझते हैं, और p99, CPU, या बैंडविड्थ में लिखित सीमा को पूरा करने के लिए पर्याप्त सुधार होता है, तो मैं वहां gRPC का उपयोग करूंगा। यूनरी और स्ट्रीमिंग मेथड्स .proto में रहते हैं, लेकिन प्रत्येक कॉल को अभी भी एक डेडलाइन मिलती है, कैंसलेशन शुरू किए गए कार्य को रोकता है, और केवल कॉन्ट्रैक्ट के अनुसार सुरक्षित ऑपरेशन्स का पुनः प्रयास किया जाता है।

इवोल्यूशन के लिए, HTTP API पेजिनेशन या एनम टूटने को पकड़ने के लिए OpenAPI डिफ्स, पुराने SDKs और सेमेंटिक रीप्ले का उपयोग करता है। Protobuf फ़ील्ड नंबर कभी नहीं बदलते हैं, हटाए गए फ़ील्ड्स रिज़र्व होते हैं, और पुराने/नए क्लाइंट-सर्वर जोड़े क्रॉस-परीक्षित होते हैं। यदि पब्लिक और आंतरिक इंटरफ़ेस एक क्षमता साझा करते हैं, तो एक डोमेन कार्यान्वयन HTTP एडेप्टर और gRPC सेवा को सर्व करता है, या मैपिंग सत्यापित होने के बाद JSON ट्रांसकोडिंग का उपयोग करता है।

मैं कॉलर द्वारा कैनरी करूंगा और एंड-टू-एंड p99, CPU, बाइट्स, स्टेटस मैपिंग, पुनः प्रयास प्रवर्धन और ट्रेस पूर्णता पर नज़र रखूंगा। यदि सुधार केवल माइक्रोबेंचमार्क में मौजूद है जबकि प्रोडक्शन की बाधा डेटाबेस बनी हुई है, तो मैं केवल प्रोटोकॉल एकरूपता के लिए माइग्रेशन का विस्तार नहीं करूंगा।”

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

• REST को HTTP/1.1 के बराबर मानना → HTTP सेमेंटिक्स और ट्रांसपोर्ट वर्ज़न में भ्रम हो रहा है → बताएं कि REST API HTTP/2 या HTTP/3 पर चल सकता है।
• यह दावा करना कि gRPC हमेशा तेज़ होता है → स्टोरेज, व्यावसायिक लॉजिक या प्रॉक्सीज़ का प्रभाव अधिक हो सकता है → प्रतिनिधि पेलोड और टेल लेटेंसी के साथ समान डोमेन कार्य को बेंचमार्क करें।
• यह कहना कि REST का कोई मजबूत कॉन्ट्रैक्ट नहीं है → यह OpenAPI विवरण, जनरेशन और परीक्षण की उपेक्षा करता है → वास्तविक कॉन्ट्रैक्ट वर्कफ़्लो की तुलना करें, न कि किसी उपेक्षित विनिर्देश की तुलना एक अनुरक्षित विनिर्देश से करें।
• ब्राउज़र से सीधे नेटिव gRPC को कॉल करना → ब्राउज़र में आवश्यक नेटिव gRPC नियंत्रण का अभाव होता है → gRPC-Web, JSON ट्रांसकोडिंग, या BFF का उपयोग करें और सीमाओं को ध्यान में रखें।
• gRPC डेडलाइन को छोड़ देना → एक क्लाइंट अनिश्चित काल तक प्रतीक्षा कर सकता है और संसाधनों का उपभोग कर सकता है → एंड-टू-एंड बजट से डेडलाइन प्राप्त करें और कैंसलेशन को सत्यापित करें।
• Protobuf वायर कम्पैटिबिलिटी को एप्लिकेशन कम्पैटिबिलिटी मानना → नए एनम्स, डिफ़ॉल्ट्स और अर्थ अभी भी कोड को तोड़ सकते हैं → वर्ज़न्स का क्रॉस-परीक्षण करें और फ़ील्ड नंबर रिज़र्व करें।
• प्रत्येक परत पर पुनः प्रयास सक्षम करना → विफलताएं ट्रैफ़िक को बढ़ाती हैं और राइट्स (writes) दोहराए जा सकते हैं → पुनः प्रयासों को केंद्रीकृत करें और सुरक्षित ऑपरेशन्स, शेष समय और प्रयासों को सीमित करें।
• केवल एकरूपता के लिए एक ही प्रोटोकॉल बनाए रखना → पब्लिक एकीकरण लागत या आंतरिक स्ट्रीमिंग आवश्यकताओं का बलिदान होता है → उचित होने पर एक स्पष्ट HTTP एज और gRPC आंतरिक सीमा का उपयोग करें।

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

फॉलो-अप 1: क्या केवल 500 QPS वाले आंतरिक API को अभी भी gRPC का उपयोग करना चाहिए?

केवल QPS निर्णय नहीं ले सकता। एक परिपक्व gRPC प्लेटफ़ॉर्म, क्रॉस-लैंग्वेज जनरेटेड कॉन्ट्रैक्ट्स और स्ट्रीमिंग आवश्यकता वाला संगठन अभी भी 500 QPS पर लाभान्वित हो सकता है। एक साधारण CRUD सेवा, परिपक्व HTTP टूलींग और पर्याप्त प्रदर्शन हेडरूम वाली टीम की परिचालन लागत संभवतः REST/HTTP+JSON के साथ कम होगी। पहले लक्ष्य मीट्रिक लिखें; यदि लाभ प्रदर्शित नहीं किया जा सकता है तो माइग्रेट न करें।

फॉलो-अप 2: एक पब्लिक मोबाइल ऐप जनरेट किए गए gRPC क्लाइंट का उपयोग कर सकता है। क्या gRPC पब्लिक API हो सकता है?

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

फॉलो-अप 3: एक .proto एक JSON API को भी कैसे प्रदर्शित कर सकता है?

HTTP मैपिंग के साथ मेथड्स को एनोटेट करें और JSON ट्रांसकोडिंग या गेटवे का उपयोग करें। रोलआउट से पहले, फ़ील्ड नाम, नल (null) और डिफ़ॉल्ट व्यवहार, HTTP और gRPC स्टेटस मैपिंग, मेटाडेटा और हेडर, प्रमाणीकरण, कैशिंग और स्ट्रीमिंग सीमाओं को सत्यापित करें। एक .proto कॉन्ट्रैक्ट स्रोत दोहराव को कम करता है, लेकिन एडेप्टर सेमेंटिक्स को अभी भी परीक्षणों की आवश्यकता होती है।

फॉलो-अप 4: gRPC स्ट्रीम बिना किसी इवेंट को खोए कैसे फिर से शुरू होती है?

प्रोटोकॉल एकल RPC के भीतर स्ट्रीमिंग और ऑर्डरिंग प्रदान करता है, न कि कोई स्थायी व्यावसायिक सदस्यता (durable business subscription)। इवेंट्स को स्थिर अनुक्रम संख्याएं दें, एक रीप्ले करने योग्य लॉग बनाए रखें, और क्लाइंट को पुन: कनेक्ट होने पर अपने उपभोग किए गए कर्सर को बनाए रखने या भेजने के लिए कहें। अवधारण (retention), समाप्त-कर्सर हैंडलिंग और डिडुप्लीकेशन को परिभाषित करें। यदि वे आवश्यकताएं हावी हैं, तो RPC को उसमें खींचने के बजाय एक संदेश लॉग या कतार (queue) की तुलना करें।

फॉलो-अप 5: एक बेंचमार्क बेहतर gRPC p99 दिखाता है, लेकिन प्रोडक्शन नहीं दिखाता। आप क्या जांचते हैं?

लेटेंसी को क्लाइंट कतारबद्धता (queuing), DNS और कनेक्शन कार्य, प्रॉक्सीज़, सीरियलाइज़ेशन, एप्लिकेशन लॉजिक, डेटाबेस और डाउनस्ट्रीम कॉल्स में विभाजित करें। जांचें कि क्या प्रोडक्शन पेलोड, कम्प्रेशन, कनेक्शन पुन: उपयोग, TLS, क्रॉस-ज़ोन रूटिंग और छिपे हुए पुनः प्रयास बेंचमार्क से मेल खाते हैं। यदि प्रोटोकॉल कुल लेटेंसी का एक छोटा सा अंश है, तो माइग्रेशन का विस्तार करने के बजाय प्रमुख घटक को अनुकूलित (optimize) करें।