देखिए कैसे AI अस्पष्ट प्रॉम्प्ट्स को प्रोडक्शन‑रेडी आर्किटेक्चर में बदल सकता है: आवश्यकताएँ फ्रेम करना, मान्यताओं को उजागर करना, ट्रेडऑफ मैप करना और डिज़ाइनों को वैलिडेट करना।
एक “अस्पष्ट प्रॉम्प्ट” सामान्य शुरुआती बिंदु होता है क्योंकि ज़्यादातर आइडियाज इरादे के रूप में शुरू होते हैं, स्पेसिफिकेशन के रूप में नहीं: “एक कस्टमर पोर्टल बनाइए,” “AI सर्च जोड़िए,” या “रियल‑टाइम में इवेंट स्ट्रीम कीजिए।” लोग परिणाम जानते हैं जो वे चाहते हैं, पर अभी सीमाएँ, जोख़िम, या इंजीनियरिंग विकल्प स्पष्ट नहीं होते।
“प्रॉम्प्ट टू आर्किटेक्चर” उस वर्कफ़्लो को कहते हैं जो उस इरादे को एक सुसंगत योजना में बदलता है: क्या बनाना है, घटक कैसे फिट होते हैं, डेटा कहाँ से बहता है, और प्रोडक्शन में काम करने के लिए क्या सच होना चाहिए।
प्रोडक्शन‑रेडी का अर्थ सिर्फ “डायग्राम हैं” नहीं है। इसका मतलब है डिज़ाइन स्पष्ट रूप से निम्न बातों को संबोधित करता है:
AI शुरुआती सोच को तेज़ करने में सक्षम है: उम्मीदवार आर्किटेक्चर जनरेट करना, सामान्य पैटर्न सुझाना (क्यूज़, कैश, सर्विस बाउंड्रीज़), गायब नॉन‑फंक्शनल आवश्यकताओं को सतह पर लाना, और इंटरफ़ेस कॉन्ट्रैक्ट या चेकलिस्ट का ड्राफ्ट तैयार करना।
AI तब गुमराह कर सकता है जब वह उन विवरणों के बारे में आत्म‑विश्वास से बोले जिन्हें वह सत्यापित नहीं कर सकता: टेक्नोलॉजी चुनना बिना संदर्भ के, ऑपरेशनल जटिलता को कम आँकना, या उन प्रतिबंधों को छोड़ देना जो केवल आपकी संस्था जानती है (कंप्लायंस, मौजूदा प्लेटफ़ॉर्म, टीम स्किल्स)। आउटपुट को स्वीकार करने से पहले चुनौती दें; इन्हें प्रपोज़ल मानें।
यह पोस्ट एक व्यावहारिक, दोहराने योग्य वर्कफ़्लो कवर करती है: प्रॉम्प्ट → आवश्यकताएँ → मान्यताएँ → विकल्प → निर्णय, साथ ही ट्रडऑफ्स जिन्हें आप ट्रेस कर सकें।
यह डोमेन एक्सपर्टाइज़, विस्तृत साइजिंग, या सुरक्षा समीक्षा बदलने का दावा नहीं करता—और न ही यह मानता है कि हर प्रॉम्प्ट के लिए एक ही “सही” आर्किटेक्चर है।
एक अस्पष्ट प्रॉम्प्ट आमतौर पर लक्ष्य (“डैशबोर्ड बनाओ”), समाधान (“माइक्रोसर्विसेज इस्तेमाल करो”), और राय (“इसे तेज़ बनाओ”) को मिलाता है। घटकों को स्केच करने से पहले, आपको एक समस्या वक्तव्य चाहिए जो परीक्षण और बहस के लायक पर्याप्त विशिष्ट हो।
एक या दो वाक्य लिखें जो प्राथमिक उपयोगकर्ता का नाम, वह काम जिसे वे करना चाहते हैं, और तात्कालिकता बताए।
उदाहरण: “कस्टमर सपोर्ट मैनेजर्स को खुले टिकट और SLA जोखिम का एक एकल दृश्य चाहिए ताकि वे रोज़ाना काम को प्राथमिकता दे सकें और इस क्वार्टर में चूकी हुई SLAs को कम कर सकें।”
अगर प्रॉम्प्ट किसी वास्तविक उपयोगकर्ता की पहचान नहीं करता, तो एक मांगें। अगर यह नहीं बताता कि यह अब क्यों मायने रखता है, तो आप बाद में ट्रेडऑफ्स रैंक नहीं कर पाएँगे।
“अच्छा” को मापने योग्य परिणामों में बदलें। उत्पाद और ऑपरेशनल संकेतों का मिश्रण पसंद करें।
एक छोटा सेट चुनें (3–5)। ज़्यादा मीट्रिक्स भ्रम पैदा करते हैं; बहुत कम जोखिम छिपाते हैं।
“हैप्पी पाथ” को सरल भाषा में वर्णन करें, फिर किन किन एज‑केसों की सूची बनाएं जो आर्किटेक्चर को आकार देंगे।
हैप्पी पाथ उदाहरण: उपयोगकर्ता साइन‑इन करता → ग्राहक खोजता → वर्तमान स्थिति देखता → फील्ड अपडेट करता → ऑडिट लॉग रिकॉर्ड होता।
एज‑केस जो जल्दी सतह पर लाएँ: ऑफ़लाइन/खराब कनेक्टिविटी, आंशिक अनुमतियाँ, डुप्लिकेट रिकॉर्ड, हाई‑वॉल्यूम इम्पोर्ट्स, टाइमआउट्स, retries, और किसी निर्भरता के डाउन होने पर क्या होता है।
यह स्पष्ट करें कि आप इस वर्शन में क्या नहीं बना रहे: अभी जिन इंटीग्रेशन का समर्थन नहीं किया जाएगा, उन्नत एनालिटिक्स, मल्टी‑रीजन, कस्टम वर्कफ़्लोज़, या पूरा एडमिन टूलिंग। स्पष्ट सीमाएँ शेड्यूल सुरक्षित रखती हैं और बाद की “फ़ेज़ 2” वार्ताओं को आसान बनाती हैं।
इन चार हिस्सों के लिखने के बाद, प्रॉम्प्ट साझा अनुबंध बन जाता है। AI इसमें परिष्कार करने में मदद कर सकता है, पर इसे खुद से नहीं आविष्कार करना चाहिए।
एक अस्पष्ट प्रॉम्प्ट अक्सर लक्ष्यों (“इसे आसान बनाओ”), फीचर्स (“नोटिफ़िकेशन भेजो”), और प्राथमिकताओं (“serverless उपयोग करो”) को एक ही वाक्य में मिलाता है। इस चरण में उन्हें अलग करें और एक ऐसी आवश्यकताएँ सूची बनायें जिसके खिलाफ आप डिज़ाइन कर सकें।
कंक्रीट व्यवहार और उन मूविंग पार्ट्स को निकालें जिनसे वे जुड़ते हैं:
एक अच्छा चेक: क्या आप हर आवश्यकता के लिए किसी स्क्रीन, API एंडपॉइंट, या बैकग्राउंड जॉब की ओर इशारा कर सकते हैं?
ये बहुत से लोगों की अपेक्षा से ज़्यादा आर्किटेक्चर को आकार देते हैं। अस्पष्ट शब्दों को मापने योग्य लक्ष्यों में बदलें:
शुरू में सीमाएँ पकड़ें ताकि आप किसी ऐसा आदर्श सिस्टम डिजाइन न करें जिसे शिप नहीं किया जा सकता:
कुछ “done means…” स्टेटमेंट लिखें जिन्हें कोई भी सत्यापित कर सके, उदाहरण:
ये आवश्यकताएँ और प्रतिबंध अगले चरण के कैंडिडेट आर्किटेक्चरों के इनपुट बन जाते हैं।
एक अस्पष्ट प्रॉम्प्ट शायद इसलिए फेल होता है क्योंकि टेक्नोलॉजी कठिन है—बल्कि इसलिए कि हर कोई चुपचाप अलग‑अलग बातें जोड़ देता है। किसी भी आर्किटेक्चर का प्रस्ताव करने से पहले, AI का उपयोग करके उन चुप्पी से भरी मान्यताओं को बाहर लाएँ और क्या सच है और क्या अनुमान है उसे अलग करें।
शुरू में उन “डिफ़ॉल्ट” बातों को लिखें जो लोग आमतौर पर संकेत करते हैं:
ये मान्यताएँ कaching, क्यूज़, स्टोरेज, मॉनिटरिंग, और लागत के चुनावों को बहुत प्रभावित करती हैं।
AI से कहें कि एक साधारण तालिका (या तीन लघु सूचियाँ) बनाये:
यह AI (और टीम) को अनुमानों को तथ्यों की तरह मानने से रोकेगा।
उपयोगी प्रश्नों में शामिल हैं:
मान्यताओं को स्पष्ट रूप से लिखें (“मान लें पीक 2,000 requests/min है”, “मान लें PII मौजूद है”)। इन्हें ड्राफ्ट इनपुट मानें जिन्हें बाद में दोबारा देखा जाना चाहिए—आदर्श रूप से हर मान्यता के साथ यह भी जोड़ें किसने और कब कन्फर्म किया। इससे बाद में ट्रेडऑफ और आर्किटेक्चर परिवर्तन को समझाना, बचाव करना और उलटना आसान होता है।
एक अस्पष्ट प्रॉम्प्ट शायद एक अकेले “सही” डिज़ाइन का संकेत नहीं देता। प्रोडक्शन‑रेडी योजना तक पहुँचने का सबसे तेज़ तरीका कुछ व्यवहार्य विकल्प स्केच करना है, फिर एक डिफ़ॉल्ट चुनना और स्पष्ट रूप से बताना कि किस शर्त पर आप स्विच करेंगे।
अधिकतर शुरुआती‑स्टेज प्रोडक्ट के लिए, एक डिप्लॉयबल बैकएंड (API + बिज़नेस लॉजिक), एक सिंगल डेटाबेस, और कुछ मैनेज्ड सर्विसेज (ऑथ, ईमेल, ऑब्जेक्ट स्टोरेज) से शुरू करें। इससे डिप्लॉयमेंट, डिबगिंग, और परिवर्तन सरल रहते हैं।
इसे चुनें जब: टीम छोटी हो, आवश्यकताएँ अभी बदल रही हों, और ट्रैफिक अनिश्चित हो।
इसी सिंगल डिप्लॉयबल के साथ स्पष्ट आंतरिक मॉड्यूल्स (billing, users, reporting) और धीमे कार्यों (इम्पोर्ट्स, नोटिफ़िकेशन, AI कॉल्स) के लिए बैकग्राउंड वर्कर जोड़ें। एक क्यू और retry नीतियाँ जोड़ें।
इसे चुनें जब: लंबी‑रनिंग टास्क हों, पीरियॉडिक स्पाइक्स हों, या स्पष्ट मालिकाना सीमाएँ चाहिए—बिना सर्विसेज में विभाजन किए।
कुछ कंपोनेंट्स को अलग‑अलग सर्विसेज में विभाजित करें जब कोई मजबूत ड्राइवर हो: सख्त आइसोलेशन (कम्प्लायंस), एक हॉटस्पॉट का स्वतंत्र स्केलिंग (जैसे मीडिया प्रोसेसिंग), या अलग रिलीज़ साइकल की ज़रूरत।
इसे चुनें जब: आप विशिष्ट लोड पैटर्न, संगठनात्मक सीमाएँ, या जोख़िम‑बाधाएँ दिखा सकें जो बढ़ी हुई ऑपरेशनल ओवरहेड को जस्टिफ़ाय करें।
इन विकल्पों में स्पष्ट बदलाव बताएं:
एक अच्छा AI‑सहायता प्राप्त आउटपुट यहाँ एक छोटा निर्णय तालिका है: “Default = A, B पर स्विच करें अगर बैकग्राउंड जॉब्स हों, C पर स्विच तब करें अगर X मेट्रिक/प्रतिबंध सच हो।” इससे प्रीमैच्योर माइक्रोसर्विसेज से बचाव होता है और आर्किटेक्चर वास्तविक आवश्यकताओं से जुड़ा रहता है।
आश्चर्यजनक रूप से बहुत सारा आर्किटेक्चर बस यह तय करना होता है कि सिस्टम का डेटा क्या है, वह कहाँ रहता है, और कौन उसे बदलने का अधिकार रखता है। अगर आप इसे जल्दी मॉडल कर लें तो बाद के चरण (घटक, इंटरफ़ेस, स्केलिंग, सुरक्षा) कम अंदाज़े पर आधारित होंगे।
शुरू करें उन कुछ ऑब्जेक्ट्स के नाम बताकर जिनके इर्द‑गिर्द सिस्टम घूमता है—आमतौर पर प्रॉम्प्ट के नाउन: User, Organization, Subscription, Order, Ticket, Document, Event। हर ऑब्जेक्ट के लिए ओनरशिप कैप्चर करें:
यहाँ AI उपयोगी है: यह प्रॉम्प्ट से प्रारम्भिक डोमेन मॉडल प्रस्तावित कर सकता है, फिर आप वास्तविक बनाम निहित की पुष्टि करें।
निर्णय लें कि हर ऑब्जेक्ट मुख्यतः transactional (OLTP)—कई छोटे रीड/राइट्स जिनमें consistency चाहिए—या analytical (aggregations, trends, reporting)। इन दोनों को एक डेटाबेस में मिलाना अक्सर तनाव पैदा करता है।
एक सामान्य पैटर्न: ऐप के लिए OLTP डेटाबेस, और इवेंट्स या एक्सपोर्ट्स से फ़ीड होने वाला अलग एनालिटिक्स स्टोर। कुंजी यह है कि स्टोरेज को डेटा के उपयोग से मिलाएँ, न कि केवल कॉन्सेप्ट के आधार पर।
डेटा सिस्टम में कैसे चलता है उसका स्केच करें:
जोख़िम स्पष्ट रूप से बताएं: PII हैंडलिंग, डुप्लिकेट रिकॉर्ड्स, conflicting sources (दो सिस्टम दोनों सच होने का दावा करते हैं), और अस्पष्ट deletion semantics। ये रिस्क सीमाएँ परिभाषित करते हैं: क्या इन‑हाउस रहना चाहिए, क्या साझा किया जा सकता है, और किन चीज़ों को ऑडिट ट्रेल या एक्सेस कंट्रोल की ज़रूरत है।
एक बार आप सीमाएँ और डेटा तय कर लें, तब उन्हें एक ठोस कम्पोनेंट मैप में बदलें: क्या मौजूद होगा, क्या उसका मालिक होगा, और वह सब कुछ कैसे बातचीत करेगा। यह वह जगह है जहाँ AI सबसे ज़्यादा उपयोगी होता है जैसे “словों में डायग्राम जेनरेटर”—यह साफ़ विभाजन प्रस्तावित कर सकता है और गायब इंटरफ़ेस को दिखा सकता है।
छोटे सेट के कम्पोनेंट्स और स्पष्ट ओनरशिप का लक्ष्य रखें। एक अच्छा चेक यह है: “अगर यह टूट गया, तो कौन इसे ठीक करेगा, और क्या बदलेगा?” उदाहरण:
डिफ़ॉल्ट कम्युनिकेशन स्टाइल चुनें और अपवादों का औचित्य दें:
AI हर उपयोग केस को सबसे सरल इंटरफ़ेस से मैप कर सकता है जो लेटेंसी और विश्वसनीयता आवश्यकताओं को पूरा करे।
तीसरी‑पक्ष सर्विसेज की सूची बनाएं और तय करें कि वे फेल होने पर क्या होता है:
एक कॉम्पैक्ट “इंटीग्रेशन तालिका” लिखें:
यह मैप implementation टिकटों और review चर्चाओं के लिए रीढ़ बनेगा।
एक डिज़ाइन व्हाइटबोर्ड पर सुंदर दिख सकता है और फिर भी पहले दिन प्रोडक्शन में फेल हो सकता है। कोड लिखने से पहले “प्रोडक्शन कॉन्ट्रैक्ट” स्पष्ट करें: लोड के दौरान, विफलताओं में, और हमले के तहत क्या होगा—और आप कैसे जानेंगे कि यह हो रहा है।
निर्भरताओं के स्लो या डाउन होने पर सिस्टम कैसे व्यवहार करेगा, यह परिभाषित कर के शुरू करें। टाइमआउट्स, retries with jitter, और स्पष्ट circuit‑breaker नियम जोड़ें। ऑपरेशन्स को idempotent बनाएं (request IDs या idempotency keys का उपयोग)।
यदि आप तीसरी‑पक्ष APIs कॉल करते हैं, तो rate limits मानकर चलें और backpressure बनाएं: क्यूज़, bounded concurrency, और graceful degradation (उदाहरण: “बाद में कोशिश करें” प्रतिक्रियाएँ)।
Authentication (कैसे यूज़र्स पहचान स्थापित करते हैं) और authorization (वे क्या एक्सेस कर सकते हैं) को निर्दिष्ट करें। उन शीर्ष थ्रेट‑सिनेरियोज़ को लिखें जो आपके सिस्टम के लिए प्रासंगिक हैं: चोरी हुए टोकन, सार्वजनिक एंडपॉइंट्स का दुरुपयोग, इनपुट के जरिए इंजेक्शन, या प्रिविलेज‑एस्केलेशन।
साथ ही यह परिभाषित करें कि सीक्रेट्स कैसे संभाले जाएंगे: वे कहाँ रहते हैं, कौन पढ़ सकता है, रोटेशन की रकम, और ऑडिट ट्रेल्स।
क्षमता और लेटेंसी लक्ष्य सेट करें (भले ही मोटे अनुमान)। फिर रणनीतियाँ चुनें: कॅशिंग (क्या, कहाँ, TTL), चैटी कॉल्स के लिए बॅचिंग, लंबी टास्क के लिए async work, और साझा संसाधनों की रक्षा के लिए सीमाएँ।
स्ट्रक्चर्ड लॉग्स, प्रमुख मेट्रिक्स (लेटेंसी, त्रुटि दर, क्यू डेप्थ), वितरित ट्रेसिंग बाउंड्रीज़, और बेसिक अलर्ट्स तय करें। हर अलर्ट को एक एक्टिविटी से जोड़ें: कौन रिस्पॉन्ड करेगा, क्या चेक करना है, और “सेफ मोड” कैसा दिखता है।
इन चुनावों को पहले‑कक्ष वास्तुकला घटकों की तरह सोचें—वे endpoints और डेटाबेस जितने महत्वपूर्ण हैं।
आर्किटेक्चर किसी एक “सर्वोत्तम” उत्तर का सेट नहीं है—यह बाधाओं के तहत चयन है। AI तेज़ी से विकल्प लिस्ट कर सकता है, पर आपको यह रिकॉर्ड करना होगा कि आपने कौन‑सा रास्ता क्यों चुना, क्या‑क्या छोड़ा, और कब आप बदलेंगे।
| विकल्प | लागत | शिप करने की गति | सादगी | स्केल हेडरूम | नोट्स / कब पुनरीक्षित करें |
|---|---|---|---|---|---|
| Managed services (DB, queues, auth) | Medium–High | High | High | High | अगर वेंडर लिमिट/फीचर नाकाफ़ी हों तो पुनरीक्षित करें |
| Self-hosted core components | Low–Medium | Low–Medium | Low | Medium–High | अगर ऑप्स का बोझ टीम की क्षमता से ऊपर चला जाए तो पुनरीक्षित करें |
| Monolith first | Low | High | High | Medium | जब डिप्लॉय फ़्रीक्वेंसी या टीम साइज माँगे तो विभाजित करें |
| Microservices early | Medium–High | Low | Low | High | सिर्फ़ तभी जब स्वतंत्र स्केलिंग/ओनरशिप अभी ज़रूरी हो |
कुछ चीज़ें स्वीकार्य विफलताएँ हों (उदा., कभी‑कभार देरी वाली ईमेल) बनाम “कभी भी फेल नहीं होना चाहिए” इलाके (उदा., पेमेंट्स, डेटा लॉस)। जहाँ विफलताएँ महंगी हैं वहाँ सुरक्षा‑उपाय रखें: बैकअप्स, idempotency, रेट‑लिमिट्स, और स्पष्ट रोलबैक पाथ्स।
कुछ डिज़ाइन्स ऑन‑कॉल लोड और डिबगिंग कठिनाई बढ़ाते हैं (ज़्यादा मूविंग पार्ट्स, ज़्यादा retries, वितरित लॉग्स)। ऐसे चुनाव चुनें जो आपके सपोर्ट‑वास्तविकता से मेल खाते हों: कम सर्विसेज, स्पष्ट ऑब्ज़र्वेबिलिटी, और अनुमानित फेल्योर मोड।
निर्णय मानदंड स्पष्ट करें: कम्प्लायंस ज़रूरतें, कस्टमाइज़ेशन, लेटेंसी, और स्टाफिंग। अगर लागत के कारण सेल्फ‑होस्टेड चुनते हैं, तो छिपी हुई कीमत नोट करें: पैचिंग, अपग्रेड्स, कैपिसिटी प्लानिंग, और इनसिडेन्ट रिस्पॉन्स।
बेहतरीन आर्किटेक्चर्स “हो कर” नहीं आते—वे कई छोटे चुनावों का परिणाम होते हैं। अगर ये चुनाव केवल चैट लॉग्स या किसी की याद में हों, तो टीमें बहस दोहराती हैं, असंगत शिपिंग होती है, और आवश्यकता बदलने पर संघर्ष होता है।
हर प्रमुख चुनाव (डेटाबेस, मेसेजिंग पैटर्न, ऑथ मॉडल, डिप्लॉयमेंट अप्रोच) के लिए Architecture Decision Record (ADR) बनाएं। इसे संक्षिप्त और सुसंगत रखें:
AI यहाँ विशेष रूप से उपयोगी है: यह विकल्पों का सारांश बना सकता है, चर्चाओं से tradeoffs निकाल सकता है, और ADRs का ड्राफ्ट तैयार कर सकता है जिन्हें आप सटीकता के लिए संपादित करें।
मान्यताएँ बदलती हैं: ट्रैफिक तेजी से बढ़ सकता है, कंप्लायंस कड़ा हो सकता है, या बाहरी API अस्थिर हो सकता है। हर प्रमुख मान्यता के लिए एक exit ramp जोड़ें:
यह भविष्य के बदलाव को एक योजनाबद्ध कदम बनाता है, अग्निशमन नहीं।
जोखिमपूर्ण चुनावों से जुड़े टेस्टेबल माइलस्टोन जोड़ें: स्पाइक्स, बेंचमार्क्स, छोटे प्रोटोटाइप्स, या लोड टेस्ट। अपेक्षित परिणाम और सफलता मानदंड रिकॉर्ड करें।
अंत में, ADRs को वर्ज़न करें जैसे आवश्यकताएँ बदलें—इतिहास को ओवरराइट नहीं करें; अपडेट्स जोड़ें ताकि आप ट्रेस कर सकें क्या, कब, और क्यों बदला। अगर हल्की संरचना चाहिए तो एक आंतरिक टेम्पलेट /blog/adr-template जैसी relative लिंक पर रखें।
एक ड्राफ्ट आर्किटेक्चर तब “ख़त्म” नहीं माना जाता जब वह डायग्राम में साफ़ दिखता है। यह तब पूरा माना जाता है जब बनाएँगे‑वाले, सुरक्षित करने वाले, चलाने वाले, और भुगतान करने वाले लोग सहमत हों कि यह काम करता है—और जब आपके पास जटिल हिस्सों का सबूत हो।
एक छोटा चेकलिस्ट उपयोग करें ताकि ज़रूरी प्रश्न जल्दी सतह पर आएँ:
आउटपुट को ठोस रखें: “हम क्या करेंगे?” और “कौन ओनर है?”—सामान्य इरादों के बजाय।
एकल थ्रूपुट अनुमान के बजाय लोड और कॉस्ट रेंजेस दें जो अनिश्चितता को दर्शाएँ:
AI से उसकी गणना और मान्यताएँ दिखाने को कहें, फिर वर्तमान analytics या तुलनात्मक सिस्टम के खिलाफ सैनीटी‑चेक करें।
महत्वपूर्ण निर्भरताओं (LLM प्रोवाइडर, वेक्टर DB, क्यू, ऑथ सर्विस) की सूची बनाएं। हर एक के लिए कैप्चर करें:
रिव्यूज़ को स्पष्ट बनाएं, न कि निहित:
जहाँ असहमति बनी रहती है, उन्हें निर्णय‑बनाने योग्य आइटम के रूप में रिकॉर्ड करें जिनके ओनर और डेट्स हों—फिर स्पष्टता के साथ आगे बढ़ें।
AI एक मजबूत डिज़ाइन पार्टनर हो सकता है यदि आप इसे जूनियर आर्किटेक्ट की तरह ट्रीट करें: विकल्प तेज़ी से जेनरेट कर सकता है, पर उसे स्पष्ट संदर्भ, चेक्स, और दिशा चाहिए।
AI को एक “बॉक्स” दें: व्यापार लक्ष्य, यूज़र्स, स्केल, बजट, डेडलाइंस, और कोई नॉन‑नेगोशिएबल्स (टेक स्टैक, कंप्लायंस, होस्टिंग)। फिर उससे पहले मान्यताओं और खुले प्रश्नों की लिस्ट माँगें और फिर समाधान प्रस्तावित कराएँ।
एक सरल नियम: अगर कोई प्रतिबंध मायने रखता है, तो उसे स्पष्ट रूप से स्टेट करें—मॉडल से इसे सर्व‑इन्फर करने की उम्मीद न करें।
यदि आपका लक्ष्य “आर्किटेक्चर योजना” से “वर्किंग सिस्टम” तक बिना हैंडऑफ़्स के जाना है, तो एक वर्कफ़्लो टूल महत्वपूर्ण है। प्लेटफ़ॉर्म जैसे Koder.ai उपयोगी हो सकते हैं क्योंकि वही चैट जो आवश्यकताएँ स्पष्ट करने में मदद करती है, वह लागुकरण में भी उन प्रतिबंधों को कैरी कर सकती है: प्लानिंग मोड, दोहराने योग्य इटरेशन्स, और जब आप तैयार हों तो सोर्स कोड एक्सपोर्ट करने की क्षमता।
यह आर्किटेक्चर रिव्यूज़ की ज़रूरत को नहीं हटाता—अगर कुछ है तो यह अनिवार्य बनाता है कि मान्यताओं और नॉन‑फंक्शनल आवश्यकताओं का दस्तावेज़ीकरण बेहतर हो—क्योंकि आप प्रपोज़ल से रनिंग ऐप तक जल्दी जा सकते हैं।
छोटे टेम्पलेट्स इस्तेमा करें जो संरचित आउटपुट देते हों:
You are helping design a system.
Context: <1–3 paragraphs>
Constraints: <bullets>
Non-functional requirements: <latency, availability, security, cost>
Deliverables:
1) Assumptions + open questions
2) 2–3 candidate architectures with pros/cons
3) Key tradeoffs (what we gain/lose)
4) Draft ADRs (decision, alternatives, rationale, risks)
(ध्यान दें: ऊपर का कोड ब्लॉक उसी रूप में छोड़ा गया है—कोड फेन्स के भीतर अनुवाद न करें।)
पहला पास माँगें, फिर तुरंत एक आलोचना माँगें:
यह मॉडल को जल्द किसी एक पथ पर लॉक होने से रोकता है।
AI आत्म‑विश्वास से बोल सकता है पर गलत भी हो सकता है। सामान्य समस्याएँ:
आप आउटपुट्स को हल्के ADRs के रूप में कैप्चर कर सकते हैं और उन्हें रिपो के साथ रख सकते हैं (देखें /blog/architecture-decision-records)।
एक अस्पष्ट प्रॉम्प्ट: “एक सिस्टम बनाइए जो ग्राहकों को सूचित करे जब डिलीवरी लेट होगी।”
AI मदद करता है इसे कंक्रीट जरूरतों में ट्रांसलेट करने में:
दो शुरुआती प्रश्न अक्सर डिज़ाइन पलट देते हैं:
इनको लिखकर आप गलत चीज़ जल्दी बनाने से रोकते हैं।
AI कैंडिडेट आर्किटेक्चर सुझाता है:
विकल्प 1: सिंक्रोनस API: carrier webhook → delay scoring service → notification service
विकल्प 2: क्यू‑आधारित: webhook → enqueue event → workers score delays → notifications
ट्रेडऑफ निर्णय: अगर carrier विश्वसनीयता और ट्रैफ़िक स्पाइक्स जोखिम हैं तो queue‑based चुनें; अगर वॉल्यूम कम है और carrier SLA मजबूत हैं तो synchronous चुनें।
बिल्ड करने लायक बनाने के लिए डिलिवरेबल्स:
“प्रॉम्प्ट टू आर्किटेक्चर” उस वर्कफ़्लो को कहता है जिसमें किसी इरादे (जैसे “कस्टमर पोर्टल बनाओ”) को एक बनाकर-लायक योजना में बदला जाता है: आवश्यकताएँ, मान्यताएँ, विकल्प, स्पष्ट निर्णय, और पूरे सिस्टम के घटक व डेटा फ्लो।
AI के आउटपुट को एक प्रस्ताव मानें जिसे आप परखें और एडिट करें—अंतिम उत्तर नहीं।
प्रोडक्शन-रेडी होने का मतलब सिर्फ डायग्राम होना नहीं है। इसका अर्थ है कि डिज़ाइन स्पष्ट रूप से कवर करता है:
डायग्राम मदद करते हैं, पर वे परिभाषा नहीं हैं।
1–2 वाक्य लिखें जो बताएँ:
अगर प्रॉम्प्ट किसी वास्तविक यूजर या तात्कालिकता का जिक्र नहीं करता, तो उन्हें मांगें—अन्यथा आप बाद में ट्रेडऑफ नहीं रैंक कर पाएँगे।
3–5 मापने योग्य मीट्रिक्स चुनें जो प्रोडक्ट और ऑपरेशनल संकेतों का मिश्रण हों, उदाहरण:
“मेट्रिक स्प्रॉल” से बचें: ज़्यादा मीट्रिक्स प्राथमिकताओं को अस्पष्ट कर देते हैं; बहुत कम जोखिम छुपा लेते हैं।
प्रारम्भ में छुपी मान्यताएँ लिख दें (ट्रैफिक, डेटा क्वालिटी, उपयोगकर्ता व्यवहार, ऑन‑कॉल कवरेज)। फिर उन्हें तीन कॉलम में बाँटें:
मान्यताओं को स्पष्ट रूप से डॉक्यूमेंट करें (किसने/कब कन्फर्म किया) ताकि बाद में चुनौती दी जा सके।
शुरुआत में कई वैध विकल्प पेश करें और एक डिफ़ॉल्ट चुनें, साथ ही स्पष्ट बताएं कि कब आप स्विच करेंगे, उदाहरण:
मकसद: ट्रेसएबल ट्रेडऑफ्स, न कि एक “एकल सही” उत्तर।
मुख्य डोमेन ऑब्जेक्ट्स (नाउन) नामित करें, जैसे User, Order, Ticket, Event। हर ऑब्जेक्ट के लिए परिभाषित करें:
हर निर्भरता (पेमेंट, मैसेजिंग, LLM, इत्यादि) के लिए विफलता व्यवहार पर निर्णय लें:
रेट‑लिमिट्स को मान लें और बैकप्रेशर डिजाइन करें ताकि स्पाइक्स cascade कर के आउटेज न बनाएँ।
प्रत्येक महत्वपूर्ण निर्णय के लिए एक ADR रखें जिसमें शामिल हो:
प्रत्येक प्रमुख अनुमिति के लिए “exit ramps” जोड़ें (ट्रिगर‑आधारित): “अगर X RPS पार हो गया तो read replicas जोड़ें”। ADRs सर्चेबल और वर्जन‑किए हुए रखें; हल्की टेम्पलेट /blog/adr-template जैसी relative लिंक पर रखी जा सकती है।
AI को एक संकुचित बॉक्स दें: उद्देश्य, यूज़र्स, स्केल, बजट/डेडलाइंस, नॉन‑नेगोशिएबल्स (स्टैक, कंप्लायंस, होस्टिंग)। उससे पूछें:
फिर “critique and refine” लूप चलाएँ: “यह डिज़ाइन किसमें नाज़ुक है?”, “कौन से requirements अभी भी अधूरे हैं?”, “आधे समय में क्या सरल करेंगे?”। आत्मविश्वासी लेकिन अनवेरिफ़ाइड स्पेसिफ़िक्स पर सावधान रहें और स्पष्ट अनिश्चितता माँगें।
फिर स्टोरेज पैटर्न को उपयोग के तरीके (OLTP बनाम एनालिटिक्स) के अनुरूप चुनें और ingestion → transformation → retention का end‑to‑end फ्लो स्केच करें।