Software Engineering — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 2726 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
2726 questions
2701
EN + हिं Easy
GB What is 'domain-driven design' (DDD) and what does a 'bounded context' specifically prevent?
IN 'डोमेन-संचालित डिज़ाइन' (डीडीडी) क्या है और 'सीमाबद्ध संदर्भ' विशेष रूप से क्या रोकता है?
A
Bounded context limits the number of developers who can work on a project simultaneously बंधा हुआ संदर्भ उन डेवलपर्स की संख्या को सीमित करता है जो किसी प्रोजेक्ट पर एक साथ काम कर सकते हैं
B
DDD models software around business domains and their terminology; a bounded context defines the scope within which a domain model and its terminology (ubiquitous language) are consistent — it prevents the 'model conflation' problem where the same term (e.g., 'Customer') means different things in different parts of the system, causing confusion and design errors डीडीडी व्यावसायिक डोमेन और उनकी शब्दावली के आसपास सॉफ्टवेयर मॉडल करता है; एक सीमित संदर्भ उस दायरे को परिभाषित करता है जिसके भीतर एक डोमेन मॉडल और उसकी शब्दावली (सर्वव्यापी भाषा) सुसंगत होती है - यह 'मॉडल कन्फ़्लेशन' समस्या को रोकता है जहां एक ही शब्द (उदाहरण के लिए, 'ग्राहक') का अर्थ सिस्टम के विभिन्न हिस्सों में अलग-अलग चीजें हैं, जिससे भ्रम और डिजाइन त्रुटियां होती हैं।
C
Bounded context requires all microservices to share the exact same data model बंधे हुए संदर्भ के लिए सभी माइक्रोसर्विसेज को बिल्कुल समान डेटा मॉडल साझा करने की आवश्यकता होती है
D
DDD is only applicable to financial software systems, not other domains डीडीडी केवल वित्तीय सॉफ्टवेयर सिस्टम पर लागू है, अन्य डोमेन पर नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) In a retail system, 'Customer' in the Sales context means someone with purchase history and loyalty points; 'Customer' in the Support context means someone with ticket history and SLA tier; 'Customer' in Billing means someone with payment methods and invoices. Trying to build one unified 'Customer' class for all three creates an unwieldy God object. Bounded contexts allow each subsystem its own 'Customer' model, integrated through translation at context boundaries rather than forcing artificial unification.
व्याख्या (हिन्दी) खुदरा प्रणाली में, बिक्री के संदर्भ में 'ग्राहक' का मतलब खरीद इतिहास और वफादारी अंक वाला कोई व्यक्ति है; समर्थन संदर्भ में 'ग्राहक' का अर्थ टिकट इतिहास और एसएलए स्तर वाला कोई व्यक्ति है; बिलिंग में 'ग्राहक' का अर्थ भुगतान विधियों और चालान वाला कोई व्यक्ति है। तीनों के लिए एक एकीकृत 'ग्राहक' वर्ग बनाने का प्रयास एक बोझिल ईश्वर वस्तु बनाता है। बंधे हुए संदर्भ प्रत्येक उपप्रणाली को अपने स्वयं के 'ग्राहक' मॉडल की अनुमति देते हैं, जो कृत्रिम एकीकरण को मजबूर करने के बजाय संदर्भ सीमाओं पर अनुवाद के माध्यम से एकीकृत होता है।
2702
EN + हिं Hard
GB What is 'idempotency' in distributed system design and why is it specifically critical for payment processing APIs?
IN वितरित सिस्टम डिज़ाइन में 'इडेम्पोटेंसी' क्या है और यह भुगतान प्रसंस्करण एपीआई के लिए विशेष रूप से महत्वपूर्ण क्यों है?
A
Idempotency means an operation always returns the same response time regardless of load इडेम्पोटेंसी का मतलब है कि एक ऑपरेशन लोड की परवाह किए बिना हमेशा एक ही प्रतिक्रिया समय देता है
B
An idempotent operation produces the same result whether executed once or multiple times — critical for payments because network failures cause clients to retry requests uncertain whether the original succeeded; without idempotency, retries could charge a customer multiple times for one purchase एक इडेम्पोटेंट ऑपरेशन एक ही परिणाम उत्पन्न करता है चाहे उसे एक बार या कई बार निष्पादित किया जाए - भुगतान के लिए महत्वपूर्ण है क्योंकि नेटवर्क विफलताओं के कारण ग्राहकों को अनुरोधों को फिर से प्रयास करना पड़ता है, यह अनिश्चित होता है कि मूल सफल हुआ या नहीं; निष्क्रियता के बिना, पुनर्प्रयास एक ग्राहक से एक खरीदारी के लिए कई बार शुल्क ले सकता है
C
Idempotency only applies to read operations; write operations cannot be made idempotent इडेम्पोटेंसी केवल पढ़ने के संचालन पर लागू होती है; लेखन संचालन को निष्क्रिय नहीं बनाया जा सकता
D
Idempotency is guaranteed automatically by all HTTP POST requests without additional implementation अतिरिक्त कार्यान्वयन के बिना सभी HTTP POST अनुरोधों द्वारा स्वचालित रूप से निष्क्रियता की गारंटी दी जाती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Payment APIs implement idempotency keys: the client generates a unique key per logical transaction and includes it with every retry of the same request. The server checks if it has already processed that key — if so, it returns the cached result without re-executing the charge. This solves the 'did my request succeed?' uncertainty inherent to distributed systems where network timeouts don't tell you whether the server actually processed the request before the connection dropped.
व्याख्या (हिन्दी) भुगतान एपीआई निष्क्रियता कुंजी लागू करते हैं: क्लाइंट प्रति तार्किक लेनदेन के लिए एक अद्वितीय कुंजी उत्पन्न करता है और इसे उसी अनुरोध के प्रत्येक पुनः प्रयास के साथ शामिल करता है। सर्वर जाँच करता है कि क्या उसने उस कुंजी को पहले ही संसाधित कर लिया है - यदि हां, तो यह चार्ज को दोबारा निष्पादित किए बिना कैश्ड परिणाम लौटाता है। इससे 'क्या मेरा अनुरोध सफल हुआ?' का समाधान हो जाता है। वितरित सिस्टम में अंतर्निहित अनिश्चितता जहां नेटवर्क टाइमआउट आपको यह नहीं बताता है कि कनेक्शन बंद होने से पहले सर्वर ने वास्तव में अनुरोध संसाधित किया था या नहीं।
2703
EN + हिं Easy
GB What is 'circuit breaker pattern' in microservices and what three states does it cycle through?
IN माइक्रोसर्विसेज में 'सर्किट ब्रेकर पैटर्न' क्या है और यह किन तीन अवस्थाओं से होकर गुजरता है?
A
Circuit breaker patterns only apply to electrical hardware components, not software systems सर्किट ब्रेकर पैटर्न केवल विद्युत हार्डवेयर घटकों पर लागू होते हैं, सॉफ़्टवेयर सिस्टम पर नहीं
B
Circuit breaker prevents cascading failures by monitoring calls to a downstream service and 'tripping' when failure rate exceeds a threshold — it cycles through: Closed (normal operation, calls pass through), Open (failures detected, calls fail immediately without attempting the downstream service), Half-Open (after a timeout, test calls are allowed to check if the service has recovered) सर्किट ब्रेकर डाउनस्ट्रीम सेवा पर कॉल की निगरानी करके और विफलता दर एक सीमा से अधिक होने पर 'ट्रिपिंग' करके कैस्केडिंग विफलताओं को रोकता है - यह चक्रित होता है: बंद (सामान्य ऑपरेशन, कॉल पास हो जाती है), ओपन (विफलताओं का पता चला, डाउनस्ट्रीम सेवा का प्रयास किए बिना कॉल तुरंत विफल हो जाती है), हाफ-ओपन (टाइमआउट के बाद, परीक्षण कॉल को यह जांचने की अनुमति दी जाती है कि सेवा ठीक हो गई है या नहीं)
C
Circuit breakers are only relevant for systems using synchronous REST APIs, not asynchronous messaging सर्किट ब्रेकर केवल सिंक्रोनस REST API का उपयोग करने वाले सिस्टम के लिए प्रासंगिक हैं, एसिंक्रोनस मैसेजिंग के लिए नहीं
D
The circuit breaker pattern guarantees zero downtime for the protected downstream service सर्किट ब्रेकर पैटर्न संरक्षित डाउनस्ट्रीम सेवा के लिए शून्य डाउनटाइम की गारंटी देता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Without circuit breakers, when Service B becomes slow/unresponsive, Service A keeps calling it, exhausting A's thread pool waiting for timeouts — A itself becomes unresponsive, and this cascades to A's callers (Service Z calling A also exhausts its resources). The circuit breaker's Open state fails fast (immediate error, no wasted waiting), protecting Service A's resources and giving Service B breathing room to recover without continued load.
व्याख्या (हिन्दी) सर्किट ब्रेकर के बिना, जब सेवा बी धीमी/अनुत्तरदायी हो जाती है, तो सेवा ए इसे कॉल करना जारी रखती है, टाइमआउट के इंतजार में ए के थ्रेड पूल को समाप्त कर देती है - ए स्वयं अनुत्तरदायी हो जाता है, और यह ए के कॉल करने वालों के लिए कैस्केड हो जाता है (सेवा जेड कॉलिंग ए भी अपने संसाधनों को समाप्त कर देता है)। सर्किट ब्रेकर की खुली स्थिति तेजी से विफल हो जाती है (तत्काल त्रुटि, कोई व्यर्थ प्रतीक्षा नहीं), सेवा ए के संसाधनों की रक्षा करती है और सेवा बी को निरंतर लोड के बिना ठीक होने के लिए सांस लेने की जगह देती है।
2704
EN + हिं Easy
GB What is 'saga pattern' in distributed transactions and what consistency model does it provide compared to ACID transactions?
IN वितरित लेनदेन में 'सागा पैटर्न' क्या है और यह ACID लेनदेन की तुलना में कौन सा स्थिरता मॉडल प्रदान करता है?
A
Saga pattern provides identical strong consistency guarantees to traditional ACID database transactions सागा पैटर्न पारंपरिक ACID डेटाबेस लेनदेन के लिए समान मजबूत स्थिरता की गारंटी प्रदान करता है
B
Saga pattern coordinates a sequence of local transactions across multiple services, each with a compensating transaction that undoes its effect if a later step fails — providing eventual consistency rather than ACID's immediate consistency, since there's no global lock across all services during the saga's execution सागा पैटर्न कई सेवाओं में स्थानीय लेनदेन के अनुक्रम को समन्वयित करता है, प्रत्येक एक क्षतिपूर्ति लेनदेन के साथ जो बाद के चरण विफल होने पर इसके प्रभाव को कम कर देता है - एसीआईडी ​​की तत्काल स्थिरता के बजाय अंततः स्थिरता प्रदान करता है, क्योंकि गाथा के निष्पादन के दौरान सभी सेवाओं में कोई वैश्विक लॉक नहीं होता है
C
Saga pattern eliminates the need for any error handling in distributed transaction scenarios सागा पैटर्न वितरित लेनदेन परिदृश्यों में किसी भी त्रुटि प्रबंधन की आवश्यकता को समाप्त करता है
D
Saga pattern only works with synchronous communication and cannot use asynchronous messaging सागा पैटर्न केवल सिंक्रोनस संचार के साथ काम करता है और एसिंक्रोनस मैसेजिंग का उपयोग नहीं कर सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A travel booking saga: reserve flight (T1), reserve hotel (T2), charge payment (T3). If T3 fails after T1 and T2 succeeded, compensating transactions run: cancel hotel (C2), cancel flight (C1) — undoing the partial work. This is fundamentally different from ACID's all-or-nothing atomicity (impossible across service boundaries without distributed locks that kill scalability) — the system passes through temporarily inconsistent intermediate states before reaching eventual consistency.
व्याख्या (हिन्दी) एक यात्रा बुकिंग गाथा: आरक्षित उड़ान (T1), आरक्षित होटल (T2), शुल्क भुगतान (T3)। यदि T1 और T2 के सफल होने के बाद T3 विफल हो जाता है, तो क्षतिपूर्ति लेनदेन चलता है: होटल रद्द करें (C2), उड़ान रद्द करें (C1) - आंशिक कार्य को पूर्ववत करना। यह मूल रूप से ACID की ऑल-ऑर-नथिंग एटोमिसिटी (स्केलेबिलिटी को खत्म करने वाले वितरित लॉक के बिना सेवा सीमाओं के पार असंभव) से अलग है - सिस्टम अंतिम स्थिरता तक पहुंचने से पहले अस्थायी रूप से असंगत मध्यवर्ती राज्यों से गुजरता है।
2705
EN + हिं Easy
GB What is 'anti-corruption layer' (ACL) in DDD and what specific integration problem does it solve?
IN डीडीडी में 'भ्रष्टाचार विरोधी परत' (एसीएल) क्या है और यह किस विशिष्ट एकीकरण समस्या का समाधान करती है?
A
ACL is a security layer that prevents malware from corrupting application data ACL एक सुरक्षा परत है जो मैलवेयर को एप्लिकेशन डेटा को दूषित करने से रोकती है
B
ACL is a translation layer isolating your domain model from an external system's (often legacy or third-party) different and potentially poor model — solving the problem where direct integration would force your clean domain model to absorb the external system's inconsistencies, naming conflicts, or design flaws एसीएल एक अनुवाद परत है जो आपके डोमेन मॉडल को बाहरी सिस्टम (अक्सर विरासत या तीसरे पक्ष) के अलग और संभावित रूप से खराब मॉडल से अलग करती है - उस समस्या को हल करना जहां प्रत्यक्ष एकीकरण आपके स्वच्छ डोमेन मॉडल को बाहरी सिस्टम की विसंगतियों, नामकरण संघर्षों, या डिज़ाइन त्रुटियों को अवशोषित करने के लिए मजबूर करेगा।
C
Anti-corruption layers are only needed when integrating with databases, not with APIs भ्रष्टाचार-रोधी परतों की आवश्यकता केवल डेटाबेस के साथ एकीकृत करते समय होती है, एपीआई के साथ नहीं
D
ACL eliminates the need for any data validation when receiving external data बाहरी डेटा प्राप्त करते समय एसीएल किसी भी डेटा सत्यापन की आवश्यकता को समाप्त कर देता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Integrating with a 1990s mainframe inventory system that uses cryptic field names, inconsistent date formats, and a fundamentally different conceptual model than your clean modern domain would, without an ACL, pollute your domain with the legacy system's quirks. The ACL translates: legacy 'ITM_STAT=A' becomes your domain's clean 'ItemStatus.Available' enum, isolating your bounded context's model purity from the external system's accidental complexity.
व्याख्या (हिन्दी) 1990 के दशक के मेनफ्रेम इन्वेंट्री सिस्टम के साथ एकीकरण, जो आपके स्वच्छ आधुनिक डोमेन की तुलना में गुप्त फ़ील्ड नाम, असंगत दिनांक प्रारूप और मौलिक रूप से भिन्न वैचारिक मॉडल का उपयोग करता है, एसीएल के बिना, आपके डोमेन को विरासत प्रणाली की विचित्रताओं से प्रदूषित कर देगा। ACL अनुवाद करता है: विरासत 'ITM_STAT=A' आपके डोमेन का स्वच्छ 'ItemStatus.Available' एनम बन जाता है, जो आपके बंधे हुए संदर्भ की मॉडल शुद्धता को बाहरी सिस्टम की आकस्मिक जटिलता से अलग कर देता है।
2706
EN + हिं Easy
GB What is 'database per service' pattern in microservices and what consistency trade-off does it introduce?
IN माइक्रोसर्विसेज में 'डेटाबेस प्रति सेवा' पैटर्न क्या है और यह किस स्थिरता व्यापार-बंद का परिचय देता है?
A
Database per service means each developer gets their own personal database for testing प्रति सेवा डेटाबेस का मतलब है कि प्रत्येक डेवलपर को परीक्षण के लिए अपना निजी डेटाबेस मिलता है
B
Each microservice owns and exclusively accesses its own database, with no other service allowed direct access — this enables service independence (schema changes don't break other services) but introduces the trade-off that queries spanning multiple services' data can no longer use simple SQL joins, requiring API composition or data duplication via events प्रत्येक माइक्रोसर्विस अपने स्वयं के डेटाबेस का मालिक है और विशेष रूप से उस तक पहुंचता है, किसी अन्य सेवा को सीधे पहुंच की अनुमति नहीं है - यह सेवा स्वतंत्रता को सक्षम बनाता है (स्कीमा परिवर्तन अन्य सेवाओं को नहीं तोड़ता है) लेकिन व्यापार-बंद का परिचय देता है कि एकाधिक सेवाओं के डेटा को फैलाने वाले प्रश्न अब सरल एसक्यूएल जॉइन का उपयोग नहीं कर सकते हैं, घटनाओं के माध्यम से एपीआई संरचना या डेटा डुप्लिकेशन की आवश्यकता होती है
C
Database per service is only applicable when using cloud-hosted databases; on-premise systems cannot use this pattern प्रति सेवा डेटाबेस केवल क्लाउड-होस्टेड डेटाबेस का उपयोग करते समय लागू होता है; ऑन-प्रिमाइसेस सिस्टम इस पैटर्न का उपयोग नहीं कर सकते
D
This pattern eliminates all data consistency concerns since each service has full control of its data यह पैटर्न सभी डेटा स्थिरता संबंधी चिंताओं को समाप्त कर देता है क्योंकि प्रत्येक सेवा का अपने डेटा पर पूर्ण नियंत्रण होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A monolith's 'show me all orders with customer details and product names' is a simple SQL JOIN. In microservices with database-per-service, Orders, Customers, and Products live in separate databases owned by separate services — there's no cross-database JOIN. Solutions: API composition (call all three services, merge results in application code — slower, more complex) or maintaining a denormalised read-only copy of needed data via event subscription (faster reads, eventual consistency, additional storage).
व्याख्या (हिन्दी) एक मोनोलिथ का 'ग्राहक विवरण और उत्पाद नाम के साथ मुझे सभी ऑर्डर दिखाएं' एक सरल एसक्यूएल जॉइन है। डेटाबेस-प्रति-सेवा वाले माइक्रोसर्विसेज में, ऑर्डर, ग्राहक और उत्पाद अलग-अलग सेवाओं के स्वामित्व वाले अलग-अलग डेटाबेस में रहते हैं - कोई क्रॉस-डेटाबेस जॉइन नहीं है। समाधान: एपीआई संरचना (सभी तीन सेवाओं को कॉल करें, एप्लिकेशन कोड में परिणाम मर्ज करें - धीमी, अधिक जटिल) या ईवेंट सदस्यता के माध्यम से आवश्यक डेटा की एक असामान्य रीड-ओनली कॉपी बनाए रखना (तेज रीड, अंतिम स्थिरता, अतिरिक्त भंडारण)।
2707
EN + हिं Easy
GB What is 'sidecar pattern' in cloud-native architecture and what cross-cutting concerns does it typically handle?
IN क्लाउड-नेटिव आर्किटेक्चर में 'साइडकार पैटर्न' क्या है और यह आम तौर पर किन क्रॉस-कटिंग चिंताओं को संभालता है?
A
Sidecar pattern only applies to mobile applications running on motorcycle delivery apps साइडकार पैटर्न केवल मोटरसाइकिल डिलीवरी ऐप्स पर चलने वाले मोबाइल एप्लिकेशन पर लागू होता है
B
Sidecar pattern deploys a helper container alongside the main application container (in the same pod) to handle cross-cutting concerns — typically: service mesh networking (mTLS, retries, load balancing via Istio/Linkerd), logging aggregation, and configuration management — without modifying the main application's code साइडकार पैटर्न क्रॉस-कटिंग चिंताओं को संभालने के लिए मुख्य एप्लिकेशन कंटेनर (उसी पॉड में) के साथ एक सहायक कंटेनर तैनात करता है - आम तौर पर: सर्विस मेश नेटवर्किंग (एमटीएलएस, रिट्रीज़, इस्तियो/लिंकरड के माध्यम से लोड संतुलन), लॉगिंग एकत्रीकरण, और कॉन्फ़िगरेशन प्रबंधन - मुख्य एप्लिकेशन के कोड को संशोधित किए बिना
C
Sidecar pattern requires every microservice to be rewritten in the same programming language as the sidecar साइडकार पैटर्न के लिए प्रत्येक माइक्रोसर्विस को साइडकार के समान प्रोग्रामिंग भाषा में फिर से लिखने की आवश्यकता होती है
D
Sidecar containers replace the need for the main application container entirely साइडकार कंटेनर मुख्य एप्लिकेशन कंटेनर की आवश्यकता को पूरी तरह से बदल देते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Istio's Envoy sidecar intercepts all network traffic to/from the application container, handling mTLS encryption, retries, circuit breaking, and observability — without the application code knowing or caring. This separates infrastructure concerns (which evolve independently and require specialised expertise) from business logic (which the application team owns) — enabling polyglot microservices to get consistent networking behaviour regardless of their implementation language.
व्याख्या (हिन्दी) इस्तियो का एन्वॉय साइडकार एप्लिकेशन कंटेनर से सभी नेटवर्क ट्रैफ़िक को रोकता है, एमटीएलएस एन्क्रिप्शन, रिट्रीज़, सर्किट ब्रेकिंग और ऑब्जर्वेबिलिटी को संभालता है - एप्लिकेशन कोड को जानने या देखभाल किए बिना। यह बुनियादी ढांचे संबंधी चिंताओं (जो स्वतंत्र रूप से विकसित होती हैं और विशेष विशेषज्ञता की आवश्यकता होती है) को व्यावसायिक तर्क (जो कि एप्लिकेशन टीम के पास है) से अलग करती है - पॉलीग्लॉट माइक्रोसर्विसेज को उनकी कार्यान्वयन भाषा की परवाह किए बिना लगातार नेटवर्किंग व्यवहार प्राप्त करने में सक्षम बनाती है।
2708
EN + हिं Easy
GB What is 'event sourcing' as a persistence pattern and what audit/debugging advantage does it provide over traditional state storage?
IN दृढ़ता पैटर्न के रूप में 'इवेंट सोर्सिंग' क्या है और यह पारंपरिक राज्य भंडारण पर क्या ऑडिट/डिबगिंग लाभ प्रदान करता है?
A
Event sourcing stores only the current state of an entity, discarding all historical changes इवेंट सोर्सिंग सभी ऐतिहासिक परिवर्तनों को छोड़कर, किसी इकाई की केवल वर्तमान स्थिति को संग्रहीत करती है
B
Event sourcing persists every state-changing event (not just the current state) — providing complete audit trail (every change is recorded with who/when/why), the ability to reconstruct state at any point in history, and the ability to replay events to debug exactly how a corrupted state arose इवेंट सोर्सिंग प्रत्येक राज्य-परिवर्तनशील घटना (सिर्फ वर्तमान स्थिति नहीं) को जारी रखती है - पूर्ण ऑडिट ट्रेल प्रदान करती है (प्रत्येक परिवर्तन को कौन/कब/क्यों के साथ रिकॉर्ड किया जाता है), इतिहास में किसी भी बिंदु पर राज्य को फिर से बनाने की क्षमता, और घटनाओं को फिर से चलाने की क्षमता डीबग करने के लिए कि कैसे एक भ्रष्ट राज्य उत्पन्न हुआ
C
Event sourcing is only applicable to financial systems and cannot be used in other domains इवेंट सोर्सिंग केवल वित्तीय प्रणालियों पर लागू होती है और अन्य डोमेन में इसका उपयोग नहीं किया जा सकता है
D
Event sourcing eliminates the need for a database since events are stored only in application memory इवेंट सोर्सिंग डेटाबेस की आवश्यकता को समाप्त कर देता है क्योंकि इवेंट केवल एप्लिकेशन मेमोरी में संग्रहीत होते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Traditional CRUD storage: an account balance is updated in place — once changed, the previous value and the reason for the change are gone unless explicitly logged elsewhere. Event sourcing stores 'AccountCredited($100, reason: refund, timestamp, actor)' as an immutable fact — the current balance is derived by replaying all events. This makes 'why is this balance wrong?' answerable by examining the exact sequence of events, and supports time-travel debugging by replaying events up to any point.
व्याख्या (हिन्दी) पारंपरिक सीआरयूडी भंडारण: एक खाता शेष स्थान पर अद्यतन किया जाता है - एक बार बदलने के बाद, पिछला मूल्य और परिवर्तन का कारण समाप्त हो जाता है जब तक कि स्पष्ट रूप से कहीं और लॉग इन न किया गया हो। इवेंट सोर्सिंग स्टोर 'अकाउंटक्रेडिटेड ($100, कारण: रिफंड, टाइमस्टैम्प, एक्टर)' को एक अपरिवर्तनीय तथ्य के रूप में संग्रहीत करता है - वर्तमान शेष सभी घटनाओं को दोबारा चलाकर प्राप्त किया जाता है। इससे 'यह संतुलन ग़लत क्यों है?' घटनाओं के सटीक अनुक्रम की जांच करके जवाबदेह है, और किसी भी बिंदु तक घटनाओं को दोबारा चलाकर समय-यात्रा डिबगिंग का समर्थन करता है।
2709
EN + हिं Easy
GB What is 'bulkhead pattern' in resilience engineering and what naval metaphor does it draw from?
IN लचीलापन इंजीनियरिंग में 'बल्कहेड पैटर्न' क्या है और यह किस नौसैनिक रूपक से लिया गया है?
A
Bulkhead pattern only applies to systems running on ships and maritime navigation software बल्कहेड पैटर्न केवल जहाजों और समुद्री नेविगेशन सॉफ़्टवेयर पर चलने वाले सिस्टम पर लागू होता है
B
The bulkhead pattern partitions system resources (thread pools, connection pools) into isolated groups so that failure or resource exhaustion in one partition doesn't cascade to others — drawn from ship bulkheads that compartmentalise the hull so a breach in one compartment doesn't sink the entire ship बल्कहेड पैटर्न विभाजन सिस्टम संसाधनों (थ्रेड पूल, कनेक्शन पूल) को अलग-अलग समूहों में विभाजित करता है ताकि एक विभाजन में विफलता या संसाधन की कमी दूसरों तक न पहुंचे - जहाज के बल्कहेड से तैयार किया गया है जो पतवार को विभाजित करता है ताकि एक डिब्बे में दरार से पूरा जहाज न डूब जाए।
C
Bulkhead pattern requires physically separate servers for every microservice with no shared infrastructure बल्कहेड पैटर्न के लिए प्रत्येक माइक्रोसर्विस के लिए बिना किसी साझा बुनियादी ढांचे के भौतिक रूप से अलग सर्वर की आवश्यकता होती है
D
Bulkhead pattern is identical to the circuit breaker pattern with no meaningful distinction बल्कहेड पैटर्न बिना किसी सार्थक अंतर के सर्किट ब्रेकर पैटर्न के समान है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Without bulkheads, a single slow downstream dependency (say, a recommendation service) consuming all available threads in a shared pool starves unrelated functionality (checkout) of threads, even though checkout doesn't depend on recommendations. Bulkheading allocates separate thread pools per dependency — recommendation service's slowness exhausts only its dedicated pool, leaving checkout's pool unaffected. This isolation principle (Netflix Hystrix popularised it) prevents one weak link from sinking the entire application.
व्याख्या (हिन्दी) बल्कहेड्स के बिना, एक साझा पूल में सभी उपलब्ध थ्रेड्स का उपभोग करने वाली एक धीमी डाउनस्ट्रीम निर्भरता (मान लीजिए, एक सिफारिश सेवा) थ्रेड्स की असंबंधित कार्यक्षमता (चेकआउट) को भूखा रखती है, भले ही चेकआउट सिफारिशों पर निर्भर नहीं करता है। बल्कहेडिंग प्रत्येक निर्भरता के लिए अलग-अलग थ्रेड पूल आवंटित करता है - अनुशंसा सेवा की धीमी गति केवल उसके समर्पित पूल को समाप्त करती है, जिससे चेकआउट का पूल अप्रभावित रह जाता है। यह अलगाव सिद्धांत (नेटफ्लिक्स हिस्ट्रिक्स ने इसे लोकप्रिय बनाया) एक कमजोर लिंक को पूरे एप्लिकेशन को डूबने से रोकता है।
2710
EN + हिं Easy
GB What is 'strangler fig pattern' applied at the architectural level and what risk-managed migration strategy does it enable?
IN वास्तुशिल्प स्तर पर लागू 'स्ट्रैंगलर फ़िग पैटर्न' क्या है और यह किस जोखिम-प्रबंधित प्रवासन रणनीति को सक्षम बनाता है?
A
Strangler fig pattern requires complete system downtime during the entire migration period स्ट्रैंगलर अंजीर पैटर्न को संपूर्ण प्रवासन अवधि के दौरान पूर्ण सिस्टम डाउनटाइम की आवश्यकता होती है
B
At the architecture level, an intercepting facade (proxy/gateway) routes requests either to the legacy system or new system based on which functionality has been migrated — enabling incremental, low-risk migration where the legacy and new system coexist, with traffic gradually shifting feature by feature until the legacy system can be safely decommissioned वास्तुकला स्तर पर, एक इंटरसेप्टिंग मुखौटा (प्रॉक्सी/गेटवे) मार्ग या तो विरासत प्रणाली या नई प्रणाली के लिए अनुरोध करता है जिसके आधार पर कार्यक्षमता माइग्रेट की गई है - वृद्धिशील, कम जोखिम वाले प्रवासन को सक्षम करना जहां विरासत और नई प्रणाली सह-अस्तित्व में है, यातायात धीरे-धीरे सुविधा दर सुविधा स्थानांतरित हो रहा है जब तक कि विरासत प्रणाली को सुरक्षित रूप से डीकमीशन नहीं किया जा सकता है
C
Strangler fig pattern can only be applied to systems with fewer than 10 total features स्ट्रैंगलर अंजीर पैटर्न केवल 10 से कम कुल सुविधाओं वाले सिस्टम पर लागू किया जा सकता है
D
This pattern eliminates the need for any testing during the migration since old and new systems run in parallel यह पैटर्न माइग्रेशन के दौरान किसी भी परीक्षण की आवश्यकता को समाप्त कर देता है क्योंकि पुराने और नए सिस्टम समानांतर में चलते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A large insurance company migrating a 20-year-old mainframe policy system might route new policy creation through a modern microservice while claims processing still routes to the mainframe. As each function is reimplemented and validated, the facade's routing rules update. The risk is bounded: if the new claims service has a bug, only claims (not the still-stable policy creation) is affected, and rollback is just a routing rule change — far safer than a 'big bang' cutover.
व्याख्या (हिन्दी) 20 साल पुरानी मेनफ्रेम पॉलिसी प्रणाली को स्थानांतरित करने वाली एक बड़ी बीमा कंपनी एक आधुनिक माइक्रोसर्विस के माध्यम से नई पॉलिसी निर्माण को रूट कर सकती है, जबकि दावों की प्रोसेसिंग अभी भी मेनफ्रेम में होती है। जैसे ही प्रत्येक फ़ंक्शन को पुन: कार्यान्वित और मान्य किया जाता है, मुखौटा के रूटिंग नियम अपडेट हो जाते हैं। जोखिम सीमित है: यदि नई दावा सेवा में कोई बग है, तो केवल दावे (अभी भी स्थिर नीति निर्माण नहीं) प्रभावित होते हैं, और रोलबैक केवल एक रूटिंग नियम परिवर्तन है - 'बिग बैंग' कटओवर की तुलना में कहीं अधिक सुरक्षित।
2711
EN + हिं Easy
GB What is 'API gateway pattern' and what cross-cutting responsibilities does it centralise away from individual microservices?
IN 'एपीआई गेटवे पैटर्न' क्या है और यह व्यक्तिगत माइक्रोसर्विसेज से दूर किन क्रॉस-कटिंग जिम्मेदारियों को केंद्रीकृत करता है?
A
API gateway only forwards requests to backend services with no additional processing एपीआई गेटवे बिना किसी अतिरिक्त प्रोसेसिंग के केवल बैकएंड सेवाओं के अनुरोधों को अग्रेषित करता है
B
An API gateway centralises: authentication/authorisation (validate tokens once, not per service), rate limiting, request routing/composition, SSL termination, and response caching — removing the need for every individual microservice to implement these concerns redundantly, ensuring consistency and reducing per-service complexity एक एपीआई गेटवे केंद्रीकृत है: प्रमाणीकरण/प्राधिकरण (एक बार टोकन मान्य करें, प्रति सेवा नहीं), दर सीमित करना, अनुरोध रूटिंग/रचना, एसएसएल समाप्ति, और प्रतिक्रिया कैशिंग - इन चिंताओं को अनावश्यक रूप से लागू करने के लिए प्रत्येक व्यक्तिगत माइक्रोसर्विस की आवश्यकता को दूर करना, स्थिरता सुनिश्चित करना और प्रति-सेवा जटिलता को कम करना
C
API gateways are only used for mobile applications and cannot serve web or desktop clients एपीआई गेटवे का उपयोग केवल मोबाइल एप्लिकेशन के लिए किया जाता है और यह वेब या डेस्कटॉप क्लाइंट को सेवा प्रदान नहीं कर सकता है
D
Using an API gateway eliminates the possibility of a single point of failure in the architecture एपीआई गेटवे का उपयोग करने से आर्किटेक्चर में विफलता के एकल बिंदु की संभावना समाप्त हो जाती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Without a gateway, each of 30 microservices would need to independently implement JWT validation, rate limiting logic, and CORS handling — multiplying the chance of inconsistent or buggy implementations and the maintenance burden when auth requirements change. Centralising at the gateway means a single, well-tested implementation enforces these policies consistently. The trade-off acknowledged in the false option: the gateway itself becomes a critical component requiring high availability design (clustering, failover) since it's now a potential single point of failure.
व्याख्या (हिन्दी) गेटवे के बिना, 30 माइक्रोसर्विसेज में से प्रत्येक को JWT सत्यापन, दर सीमित करने वाले तर्क और CORS हैंडलिंग को स्वतंत्र रूप से लागू करने की आवश्यकता होगी - जब प्रामाणिक आवश्यकताएं बदलती हैं तो असंगत या खराब कार्यान्वयन और रखरखाव बोझ की संभावना बढ़ जाती है। गेटवे पर केंद्रीकरण का अर्थ है एक एकल, अच्छी तरह से परीक्षण किया गया कार्यान्वयन इन नीतियों को लगातार लागू करता है। गलत विकल्प में स्वीकार किए गए व्यापार-बंद: गेटवे स्वयं एक महत्वपूर्ण घटक बन जाता है जिसके लिए उच्च उपलब्धता डिज़ाइन (क्लस्टरिंग, फेलओवर) की आवश्यकता होती है क्योंकि यह अब विफलता का एक संभावित एकल बिंदु है।
2712
EN + हिं Medium
GB What is 'hexagonal architecture's' relationship to dependency injection and why is the domain layer the only layer with zero framework dependencies?
IN 'हेक्सागोनल आर्किटेक्चर' का निर्भरता इंजेक्शन से क्या संबंध है और डोमेन परत शून्य फ्रेमवर्क निर्भरता वाली एकमात्र परत क्यों है?
A
Hexagonal architecture requires the domain layer to directly import the database driver for performance हेक्सागोनल आर्किटेक्चर को प्रदर्शन के लिए डेटाबेस ड्राइवर को सीधे आयात करने के लिए डोमेन परत की आवश्यकता होती है
B
Hexagonal architecture uses dependency injection to invert control: the domain layer defines interfaces (ports) that infrastructure (adapters) implements, so the domain depends only on its own abstractions, never on frameworks/databases/UI — this keeps business logic testable in isolation and portable across infrastructure changes (swap MySQL for PostgreSQL without touching domain code) हेक्सागोनल आर्किटेक्चर नियंत्रण को पलटने के लिए निर्भरता इंजेक्शन का उपयोग करता है: डोमेन परत उन इंटरफेस (पोर्ट) को परिभाषित करती है जो बुनियादी ढांचे (एडेप्टर) लागू करते हैं, इसलिए डोमेन केवल अपने स्वयं के अमूर्त पर निर्भर करता है, फ्रेमवर्क/डेटाबेस/यूआई पर कभी नहीं - यह व्यवसाय तर्क को अलगाव में परीक्षण योग्य रखता है और बुनियादी ढांचे में परिवर्तन के दौरान पोर्टेबल रखता है (डोमेन कोड को छुए बिना PostgreSQL के लिए MySQL को स्वैप करें)
C
All layers in hexagonal architecture must have identical dependencies for consistency हेक्सागोनल वास्तुकला में सभी परतों में स्थिरता के लिए समान निर्भरता होनी चाहिए
D
Hexagonal architecture cannot use dependency injection because it conflicts with the ports and adapters concept हेक्सागोनल आर्किटेक्चर निर्भरता इंजेक्शन का उपयोग नहीं कर सकता क्योंकि यह पोर्ट और एडेप्टर अवधारणा के साथ टकराव करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) This is the practical implementation of DIP applied architecturally. The domain's OrderService depends on an abstract PaymentGatewayPort interface, not directly on StripeAdapter. At runtime, dependency injection wires the concrete StripeAdapter implementation in. Unit testing OrderService requires only a mock implementing PaymentGatewayPort — no real Stripe API, no database, no web framework. This is why hexagonal architecture's domain layer can achieve near-instant, fully isolated test execution.
व्याख्या (हिन्दी) यह वास्तुशिल्प रूप से लागू डीआईपी का व्यावहारिक कार्यान्वयन है। डोमेन की ऑर्डरसर्विस एक अमूर्त पेमेंटगेटवेपोर्ट इंटरफ़ेस पर निर्भर करती है, सीधे स्ट्राइपएडाप्टर पर नहीं। रनटाइम पर, निर्भरता इंजेक्शन कंक्रीट स्ट्राइपएडाप्टर कार्यान्वयन को तार देता है। यूनिट परीक्षण ऑर्डरसर्विस को केवल एक नकली कार्यान्वयन पेमेंटगेटवेपोर्ट की आवश्यकता होती है - कोई वास्तविक स्ट्राइप एपीआई नहीं, कोई डेटाबेस नहीं, कोई वेब फ्रेमवर्क नहीं। यही कारण है कि हेक्सागोनल आर्किटेक्चर की डोमेन परत लगभग तत्काल, पूरी तरह से पृथक परीक्षण निष्पादन प्राप्त कर सकती है।
2713
EN + हिं Easy
GB What is 'static analysis' versus 'dynamic analysis' in code quality enforcement and what defect categories does each catch?
IN कोड गुणवत्ता प्रवर्तन में 'स्थैतिक विश्लेषण' बनाम 'गतिशील विश्लेषण' क्या है और प्रत्येक कौन सी दोष श्रेणियां पकड़ता है?
A
Static analysis only checks code formatting; dynamic analysis only checks runtime performance स्थैतिक विश्लेषण केवल कोड स्वरूपण की जाँच करता है; गतिशील विश्लेषण केवल रनटाइम प्रदर्शन की जाँच करता है
B
Static analysis (SonarQube, ESLint) examines source code without executing it — catching style violations, null pointer risks, unused variables, complexity thresholds; dynamic analysis (profilers, sanitizers) examines behaviour during actual execution — catching memory leaks, race conditions, actual performance bottlenecks that only manifest at runtime स्थैतिक विश्लेषण (सोनारक्यूब, ईएसलिंट) स्रोत कोड को निष्पादित किए बिना उसकी जांच करता है - शैली उल्लंघन, शून्य सूचक जोखिम, अप्रयुक्त चर, जटिलता थ्रेशोल्ड को पकड़ना; गतिशील विश्लेषण (प्रोफाइलर, सैनिटाइज़र) वास्तविक निष्पादन के दौरान व्यवहार की जांच करता है - मेमोरी लीक, दौड़ की स्थिति, वास्तविक प्रदर्शन बाधाओं को पकड़ना जो केवल रनटाइम पर प्रकट होते हैं
C
Static and dynamic analysis are identical techniques with different marketing names स्थैतिक और गतिशील विश्लेषण विभिन्न विपणन नामों वाली समान तकनीकें हैं
D
Static analysis can only be performed by human reviewers; dynamic analysis is always automated स्थैतिक विश्लेषण केवल मानव समीक्षकों द्वारा ही किया जा सकता है; गतिशील विश्लेषण हमेशा स्वचालित होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Static analysis is fast and runs on every commit but has false positives/negatives because it reasons about code without knowing actual runtime values. Dynamic analysis (ASan, race detectors, profilers) catches what only manifests when code actually runs with real data and timing — but requires execution, so it's slower and requires test coverage to exercise the relevant code paths. Comprehensive quality requires both.
व्याख्या (हिन्दी) स्थैतिक विश्लेषण तेज़ है और हर प्रतिबद्धता पर चलता है लेकिन इसमें गलत सकारात्मक/नकारात्मक परिणाम होते हैं क्योंकि यह वास्तविक रनटाइम मानों को जाने बिना कोड के बारे में बताता है। गतिशील विश्लेषण (एएसएन, रेस डिटेक्टर, प्रोफाइलर) केवल तभी प्रकट होता है जब कोड वास्तव में वास्तविक डेटा और समय के साथ चलता है - लेकिन निष्पादन की आवश्यकता होती है, इसलिए यह धीमा है और प्रासंगिक कोड पथों का उपयोग करने के लिए परीक्षण कवरेज की आवश्यकता होती है। व्यापक गुणवत्ता के लिए दोनों की आवश्यकता होती है।
2714
EN + हिं Easy
GB What is 'linting' and what is the specific risk of over-aggressive linting rule enforcement on team productivity?
IN 'लिंटिंग' क्या है और टीम उत्पादकता पर अति-आक्रामक लिंटिंग नियम प्रवर्तन का विशिष्ट जोखिम क्या है?
A
Linting only checks for syntax errors that prevent code from compiling लिंटिंग केवल सिंटैक्स त्रुटियों की जाँच करता है जो कोड को संकलित होने से रोकता है
B
Linting analyses code for style and potential error patterns; over-aggressive enforcement (hundreds of strict rules, zero tolerance for any deviation) can create developer fatigue, encourage workarounds (disabling lint rules inline rather than fixing issues), and slow velocity disproportionate to the quality benefit gained लिंटिंग शैली और संभावित त्रुटि पैटर्न के लिए कोड का विश्लेषण करता है; अत्यधिक आक्रामक प्रवर्तन (सैकड़ों सख्त नियम, किसी भी विचलन के लिए शून्य सहनशीलता) डेवलपर थकान पैदा कर सकता है, वर्कअराउंड को प्रोत्साहित कर सकता है (समस्याओं को ठीक करने के बजाय लिंट नियमों को इनलाइन अक्षम कर सकता है), और प्राप्त गुणवत्ता लाभ के अनुपात में धीमी गति
C
Linting rules should always be set to maximum strictness regardless of team or project context टीम या प्रोजेक्ट संदर्भ की परवाह किए बिना लिंटिंग नियमों को हमेशा अधिकतम सख्ती पर सेट किया जाना चाहिए
D
Linting tools cannot be customised; all projects must use identical default rule sets लिंटिंग टूल को अनुकूलित नहीं किया जा सकता; सभी परियोजनाओं को समान डिफ़ॉल्ट नियम सेट का उपयोग करना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Effective lint configuration distinguishes correctness rules (catch actual bugs: unused variable that should be used, missing await) from stylistic preferences (single vs double quotes). Teams that enforce hundreds of stylistic rules with equal severity to correctness rules see developers add '// eslint-disable-next-line' comments reflexively, defeating the tool's purpose. Effective teams curate a focused rule set emphasising correctness, automate formatting (Prettier) to eliminate style debates entirely, and reserve human judgment for what tools cannot assess.
व्याख्या (हिन्दी) प्रभावी लिंट कॉन्फ़िगरेशन शैलीगत प्राथमिकताओं (एकल बनाम दोहरे उद्धरण) से शुद्धता नियमों (वास्तविक बग को पकड़ना: अप्रयुक्त चर जिसका उपयोग किया जाना चाहिए, गायब प्रतीक्षा) को अलग करता है। जो टीमें सैकड़ों शैलीगत नियमों को शुद्धता नियमों के समान गंभीरता के साथ लागू करती हैं, डेवलपर्स टूल के उद्देश्य को विफल करते हुए, '// एस्लिंट-डिसेबल-नेक्स्ट-लाइन' टिप्पणियाँ जोड़ते हैं। प्रभावी टीमें शुद्धता पर जोर देने वाले एक केंद्रित नियम सेट को क्यूरेट करती हैं, शैली संबंधी बहसों को पूरी तरह से खत्म करने के लिए फ़ॉर्मेटिंग (प्रीटियर) को स्वचालित करती हैं, और जो उपकरण मूल्यांकन नहीं कर सकते हैं उसके लिए मानवीय निर्णय को सुरक्षित रखते हैं।
2715
EN + हिं Easy
GB What is 'API versioning strategy' and what trade-off exists between URL versioning and header versioning?
IN 'एपीआई वर्जनिंग रणनीति' क्या है और यूआरएल वर्जनिंग और हेडर वर्जनिंग के बीच क्या समझौता मौजूद है?
A
API versioning is unnecessary if the API is well-documented; documentation alone prevents breaking changes यदि एपीआई अच्छी तरह से प्रलेखित है तो एपीआई संस्करण अनावश्यक है; केवल दस्तावेज़ीकरण ही परिवर्तनों को तोड़ने से रोकता है
B
URL versioning (/api/v2/users) is visible, cacheable, and easy to test but clutters the URL space and implies the resource itself changed; header versioning (Accept: application/vnd.api+json;version=2) keeps URLs clean and resource-focused but is less visible/discoverable and complicates caching and manual testing URL संस्करणीकरण (/api/v2/users) दृश्यमान, कैश करने योग्य और परीक्षण करने में आसान है, लेकिन URL स्थान को अव्यवस्थित कर देता है और इसका अर्थ है कि संसाधन स्वयं बदल गया है; हेडर वर्जनिंग (स्वीकार करें: एप्लिकेशन/vnd.api+json;version=2) यूआरएल को साफ और संसाधन-केंद्रित रखता है लेकिन कम दृश्यमान/खोजने योग्य होता है और कैशिंग और मैन्युअल परीक्षण को जटिल बनाता है
C
Both versioning strategies are functionally identical with zero practical differences दोनों संस्करण रणनीतियाँ शून्य व्यावहारिक अंतर के साथ कार्यात्मक रूप से समान हैं
D
API versioning is only relevant for public APIs; internal APIs never need version management एपीआई संस्करण केवल सार्वजनिक एपीआई के लिए प्रासंगिक है; आंतरिक एपीआई को कभी भी संस्करण प्रबंधन की आवश्यकता नहीं होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) URL versioning's visibility helps developers immediately understand which version they're calling and enables simple curl testing without header manipulation, but semantically the resource (/users/123) shouldn't change identity just because the representation format version changed. Header versioning maintains REST's principle that a resource has one URL regardless of representation, but requires developers to remember to set headers, complicating browser testing and proxy caching strategies that key on URL alone.
व्याख्या (हिन्दी) यूआरएल संस्करण की दृश्यता डेवलपर्स को तुरंत यह समझने में मदद करती है कि वे किस संस्करण को कॉल कर रहे हैं और हेडर हेरफेर के बिना सरल कर्ल परीक्षण को सक्षम बनाता है, लेकिन शब्दार्थ रूप से संसाधन (/ उपयोगकर्ता/123) को केवल इसलिए पहचान नहीं बदलनी चाहिए क्योंकि प्रतिनिधित्व प्रारूप संस्करण बदल गया है। हेडर संस्करण REST के सिद्धांत को बनाए रखता है कि एक संसाधन में प्रतिनिधित्व की परवाह किए बिना एक URL होता है, लेकिन डेवलपर्स को हेडर सेट करना याद रखना पड़ता है, जिससे ब्राउज़र परीक्षण और प्रॉक्सी कैशिंग रणनीतियाँ जटिल हो जाती हैं जो अकेले URL पर कुंजी लगाती हैं।
2701–2715 of 2726