आर्किटेक्चर रिव्यू रिपोर्ट

1. मैनेजमेंट सारांश

• सिस्टम आज का लोड संभाल लेता है, लेकिन ग्राहकों की संख्या दोगुनी होते ही रिपोर्टिंग और ऑर्डर प्रक्रिया के बॉटलनेक बनने की आशंका है।
• सबसे तात्कालिक जोखिम सुरक्षा और व्यावसायिक निरंतरता में हैं: डेटाबेस बैकअप को कभी रीस्टोर करके परखा नहीं गया, और एडमिन पैनल सभी के लिए खुला है।
• दोबारा लिखने की ज़रूरत नहीं है। सुझाया गया रास्ता यह है कि मौजूदा मोनोलिथ को 6 महीनों में मॉड्यूलों में बाँटा जाए और चरण-दर-चरण मज़बूत किया जाए।

2. दायरा और तरीका

अवधि

5 कार्यदिवस

समीक्षा का दायरा

मुख्य एप्लिकेशन का कोडबेस (लगभग 1.2 लाख पंक्तियाँ), डेटाबेस स्कीमा, सर्वर और डिप्लॉयमेंट इन्फ्रास्ट्रक्चर

साक्षात्कार

टेक लीड, दो डेवलपरों और ऑपरेशंस प्रमुख के साथ 4 साक्षात्कार

टूल

कोड रिव्यू, क्वेरी प्लान (EXPLAIN ANALYZE), डिपेंडेंसी और सुरक्षा स्कैन, लोड प्रोफ़ाइलिंग

3. निष्कर्ष

असर और तात्कालिकता के क्रम में।

1. #1गंभीरनिरंतरताअनुमानित मेहनत: 1 दिन

   रोज़ बैकअप लिया जाता है, लेकिन उसे कभी रीस्टोर करके परखा नहीं गया; बैकअप उसी सर्वर पर रखे हैं।

   असर:डिस्क खराब होने पर डेटा और बैकअप दोनों एक साथ खो जाएँगे।

   सुझाव:बैकअप को एक अलग स्थान पर ले जाएँ और हर महीने रीस्टोर टेस्ट करें।

2. #2गंभीरसुरक्षाअनुमानित मेहनत: 2 दिन

   एडमिन पैनल इंटरनेट पर खुला है; उसमें न टू-फ़ैक्टर ऑथेंटिकेशन है, न ही लॉगिन प्रयासों की कोई सीमा।

   असर:ब्रूट-फ़ोर्स हमले से सारे ग्राहक डेटा तक पहुँचा जा सकता है।

   सुझाव:पैनल को VPN या IP प्रतिबंध के पीछे रखें और 2FA व रेट लिमिटिंग जोड़ें।

3. #3उच्चप्रदर्शनअनुमानित मेहनत: 3 दिन

   मासिक रिपोर्ट क्वेरी बिना इंडेक्स वाली एक टेबल को शुरू से अंत तक स्कैन करती है (औसतन 38 सेकंड)।

   असर:रिपोर्ट चलते समय ऑर्डर स्क्रीन धीमी हो जाती हैं।

   सुझाव:दो कंपोज़िट इंडेक्स, और रिपोर्ट को रात में तैयार की गई सारांश टेबल से पढ़ना।

4. #4उच्चआर्किटेक्चरअनुमानित मेहनत: 4-6 सप्ताह

   ऑर्डर, स्टॉक और बिलिंग का कोड सीधे एक-दूसरे की टेबलों में लिखता है।

   असर:एक मॉड्यूल में बदलाव दूसरों को तोड़ देता है; नई सुविधाएँ धीमी होती जा रही हैं।

   सुझाव:मॉड्यूलों की सीमाएँ तय करें और उनके बीच का संचार एक ही सर्विस लेयर से होकर करें।

5. #5मध्यमरखरखावअनुमानित मेहनत: 2 सप्ताह

   फ़्रेमवर्क दो मेजर वर्ज़न पीछे है; 14 डिपेंडेंसी में ज्ञात कमज़ोरियाँ हैं।

   असर:सुरक्षा अपडेट लागू नहीं हो पाते, और अपग्रेड हर महीने और कठिन होता जा रहा है।

   सुझाव:पहले डिपेंडेंसी अपग्रेड करें, फिर फ़्रेमवर्क को एक-एक वर्ज़न करके।

6. #6मध्यमटीमअनुमानित मेहनत: 2-3 सप्ताह

   स्वचालित टेस्ट कवरेज 8% है; डिप्लॉयमेंट हाथ से होता है और एक ही व्यक्ति पर निर्भर है।

   असर:उस व्यक्ति की अनुपस्थिति में कुछ भी लाइव नहीं हो सकता; बग सबसे पहले ग्राहक देखते हैं।

   सुझाव:महत्वपूर्ण प्रक्रियाओं के लिए E2E टेस्ट और एक स्वचालित डिप्लॉयमेंट पाइपलाइन।

4. लक्ष्य आर्किटेक्चर

• यह एक ही एप्लिकेशन (मॉड्यूलर मोनोलिथ) बना रहता है; ऑर्डर, स्टॉक, बिलिंग और रिपोर्टिंग अलग-अलग मॉड्यूल हैं।
• रिपोर्टिंग ऐसी सारांश टेबलों से पढ़ती है जो मुख्य डेटाबेस पर लोड नहीं डालतीं।
• एडमिन पैनल आंतरिक नेटवर्क में है; डिप्लॉयमेंट स्वचालित है और उसे रोलबैक किया जा सकता है।

5. माइग्रेशन योजना

1. पहले 30 दिन

   जोखिम दूर करना

   • बैकअप और रीस्टोर टेस्ट
   • एडमिन पैनल की सुरक्षा
   • रिपोर्ट क्वेरी को तेज़ करना

2. 1-3 महीने

   नींव मज़बूत करना

   • डिपेंडेंसी और फ़्रेमवर्क अपग्रेड
   • महत्वपूर्ण प्रक्रियाओं के टेस्ट
   • स्वचालित डिप्लॉयमेंट पाइपलाइन

3. 3-6 महीने

   मॉड्यूलों में बाँटना

   • ऑर्डर और स्टॉक मॉड्यूल को अलग करना
   • बिलिंग को सर्विस लेयर पर ले जाना
   • आर्किटेक्चर दस्तावेज़ीकरण और टीम को हैंडओवर