इसे छोड़कर कंटेंट पर जाएं

ROI विश्लेषिकी और सुरक्षित पूंजी

MirApi Gateway विस्तृत विश्लेषिकी प्रदान करता है जो आपके एप्लिकेशन को मिलने वाले वास्तविक मूल्य और निवेश पर प्रतिफल (ROI) को प्रदर्शित करती है। अमूर्त अपटाइम प्रतिशत दिखाने के बजाय, गेटवे ठोस प्रदर्शन मेट्रिक्स को ट्रैक करता है, जिसमें सुरक्षित अनुरोध (Rescued Requests) और सुरक्षित पूंजी (Rescued Capital) शामिल हैं।


“सुरक्षित अनुरोध” क्या है?

Section titled ““सुरक्षित अनुरोध” क्या है?”

किसी अनुरोध को सुरक्षित (rescued) के रूप में वर्गीकृत किया जाता है यदि वह शुरुआत में विफल रहा (अपस्ट्रीम आउटेज, कनेक्शन टाइमआउट, या दर सीमाओं के कारण) लेकिन अंततः गेटवे के हस्तक्षेप से सफल हो गया।

गेटवे सुरक्षित अनुरोधों की संख्या बढ़ाता है जब:

  1. सफल पुनः प्रयास (Retries): प्राथमिक कॉल विफल रही, लेकिन एक बाद का पुनः प्रयास (X-Retry-Count) सफल रहा।
  2. सफल फ़ेलओवर (Failover): प्राथमिक URL विफल रहा, लेकिन अनुरोध X-Failover-URL पर कॉल करके सफलतापूर्वक हल हो गया।
  3. स्मार्ट कैश (Smart Cache): अपस्ट्रीम विफल रहा, और गेटवे ने एक ताज़ा कैश की गई प्रतिक्रिया (X-Smart-Cache) परोसी।
  4. कैस्केड फॉलबैक (Cascade Fallback): एक क्रमिक कैस्केड मार्ग में प्राथमिक टारगेट विफल रहा, लेकिन एक बैकअप टारगेट ने अनुरोध को सफलतापूर्वक हल कर दिया।

सुरक्षित प्रतिक्रियाओं में X-Rescued हेडर डायग्नोस्टिक होता है, जो यह दर्शाता है कि अनुरोध को कैसे बचाया गया था (cache, failover, या cascade_fallback)।


सुरक्षित पूंजी ट्रैकिंग (Rescued Capital Tracking)

Section titled “सुरक्षित पूंजी ट्रैकिंग (Rescued Capital Tracking)”

ई-कॉमर्स, बैंकिंग और भुगतान अनुप्रयोगों के लिए, एक विफल API अनुरोध सीधे राजस्व के नुकसान का प्रतिनिधित्व करता है। गेटवे स्वचालित रूप से उस लेन-देन की वित्तीय राशि की गणना करता है जिसे वह विफल होने से बचाता है।

यह कैसे काम करता है:

Section titled “यह कैसे काम करता है:”
  1. बॉडी पार्सिंग और निष्कर्षण के नियम:
    • पुनरावर्ती खोज (Recursive Search): गेटवे अनुरोध की JSON संरचना को पुनरावर्ती रूप से पार करता है।
    • लक्षित फ़ील्ड: यह amount, sum और total फ़ील्ड (केस-असंवेदनशील) की खोज करता है।
    • प्राथमिकता क्रम: यदि JSON पेलोड के एक ही स्तर पर कई फ़ील्ड मौजूद हैं (जैसे, total और amount दोनों), तो निष्कर्षण के लिए प्राथमिकता क्रम है:
      1. amount
      2. sum
      3. total
    • समर्थित डेटा प्रकार: यह float64, string, int और int64 प्रारूपों का समर्थन करता है।
  2. ट्रिगर (Trigger): निकाली गई राशि को सुरक्षित पूंजी (Rescued Capital) में केवल तभी जोड़ा जाता है जब अनुरोध सफलतापूर्वक बच जाता है (आंतरिक rescued ध्वज true हो जाता है)। यह तब होता है जब प्राथमिक अपस्ट्रीम पर किया गया पहला प्रयास विफल हो जाता है, लेकिन गेटवे के विश्वसनीयता तंत्रों में से किसी एक द्वारा सफलता प्राप्त की जाती है:
    • स्मार्ट कैश (Smart Cache): अपस्ट्रीम द्वारा 5xx त्रुटि लौटाए जाने या पहुंच से बाहर होने पर कैश से सफलतापूर्वक परोसा गया।
    • रिट्राय लॉजिक (Retry Logic): एक या अधिक स्वचालित पुनः प्रयासों के बाद सफलतापूर्वक पूरा हुआ (डायग्नोस्टिक हेडर X-Rescued: retry जोड़ा जाता है)।
    • फ़ेलओवर रूट (Failover Route): बैकअप X-Failover-URL पर रीडायरेक्ट करके बचाया गया।
    • कैस्केड रूट (Cascade Route): कॉन्फ़िगर किए गए कैस्केड टारगेट सूची में कम प्राथमिकता वाले या समानांतर बैकअप होस्ट पर सफलता प्राप्त की गई।
  3. संचय (Aggregation): बचाई गई पूंजी को मासिक आधार पर संकलित किया जाता है।

उदाहरण परिदृश्य:

  1. आपका क्लाइंट ऐप एक भुगतान अनुरोध करता है: POST /v1/charges बॉडी {"amount": 150.00, "currency": "usd"} के साथ।
  2. प्राथमिक Stripe API 502 Bad Gateway लौटाता है।
  3. MirApi Gateway विफलता को इंटरसेप्ट करता है, कुछ समय बाद अनुरोध का पुनः प्रयास करता है, और दूसरा प्रयास सफल होता है।
  4. उपयोगकर्ता को एक सफलता प्रतिक्रिया मिलती है। गेटवे पंजीकृत करता है:
    • सुरक्षित अनुरोध: +1
    • सुरक्षित पूंजी: +$150.00

डेटाबेस सिंक आर्किटेक्चर

Section titled “डेटाबेस सिंक आर्किटेक्चर”

उच्च थ्रूपुट सुनिश्चित करने और लोड के तहत डेटाबेस राइट लॉक को रोकने के लिए, गेटवे एक बफर राइटिंग आर्किटेक्चर का उपयोग करता है:

  • मेट्रिक्स को पहले Redis में परमाणु संचालन (atomic operations) का उपयोग करके संकलित किया जाता है:
    • user:metrics:<id>:total_requests
    • user:metrics:<id>:rescued_requests
    • user:metrics:<id>:rescued_capital
  • उपयोगकर्ता को Redis सेट users_metrics_to_sync में चिह्नित किया जाता है।
  • पृष्ठभूमि में चलने वाला एक फ्लशर वर्कर (StartMetricsFlusher) समय-समय पर (हर 10-30 सेकंड में) Redis से मानों को निकालता है और उन्हें PostgreSQL user_metrics तालिका में बैच में अपडेट करता है।

ये मेट्रिक्स वास्तविक समय में क्लाइंट डैशबोर्ड पर दिखाई देते हैं:

  • Rescued Requests: विफल होने से बचाए गए लेन-देनों की कुल संख्या।
  • Rescued Capital: लेन-देनों का कुल मौद्रिक मूल्य जो गेटवे के बिना विफल हो जाता।
  • सुरक्षा ROI: बचाई गई पूंजी बनाम प्रॉक्सी सदस्यता लागत का ग्राफ़िकल प्रतिनिधित्व।

ROI डैशबोर्ड विश्लेषिकी स्क्रीनशॉट