भुगतान अवलोकन और सहसंबंध (Payment Observability And Correlation)

पिछले अनुभाग में, हमने देखा कि वेबहुक और सिंक्रोनस पथ एक ही रिकॉर्ड के लिए कैसे प्रतिस्पर्धा करते हैं और संस्करण टोकन और लीज़ इसे कैसे हल करते हैं। तो जब कोई दौड़ होती है या कोई भुगतान घंटों तक FinalizePending में अटका रहता है तो आप इसे कैसे देखते हैं?

वितरित भुगतान प्रणाली में, यह कहना पर्याप्त नहीं है कि 'कुछ गलत हो गया'; किस भुगतान आईडी, किस चरण पर और किस साक्ष्य के साथ यह अटका था, इस प्रश्न का उत्तर कुछ ही सेकंड में दिया जाना चाहिए। यहां अवलोकनशीलता कोई विलासिता नहीं है - यह बुनियादी ढांचा है जो निर्धारित करता है कि सुलह कार्यकर्ता क्या स्कैन करेगा और ऑन-कॉल इंजीनियर कौन सी रनबुक खोलेगा।```text Payment #8812 ├─ trace: checkout-orchestrator ├─ step log: ChargeSent → WebhookReceived → FinalizeAttempted └─ metric: deferred_finalize_age_seconds = 847

## पहले उल्लेख पर अवधारणाएँ```text
📦 Payment ID (Correlation Spine)
Tüm servisler, loglar ve metriklerde tekrarlanan, ödeme yaşam döngüsünün birincil anahtarı.

📦 Step Event Log
Bir ödemenin her anlamlı adımını kaydeden, append-only olay dizisi.

📦 Deferred Finalize
Ödeme PSP tarafında sonuçlanmış olabilir ama local sistem henüz terminal statüye geçmemiştir.

📦 Structured Log
Serbest metin yerine alan tabanlı, sorgulanabilir log kaydı.
```अनुरोध आईडी या ट्रेस आईडी अस्थायी है; भुगतान आईडी स्थायी है. जब आपको कोई ग्राहक शिकायत प्राप्त होती है, तो आप जो खोज रहे हैं वह भुगतान आईडी है, अनुरोध आईडी नहीं।

## भुगतान आईडी: सहसंबंध की रीढ़

जब चेकआउट ऑर्केस्ट्रेटर भुगतान शुरू करता है, तो भुगतान आईडी उत्पन्न होती है और तब से प्रत्येक सेवा में ले जाया जाता है: प्रदाता गेटवे के चार्ज अनुरोध में, वेबहुक मेटाडेटा में, चरण ईवेंट लॉग में, मीट्रिक टैग में। यह आईडी बिखरे हुए निशानों को एक कहानी से जोड़ती है।```text
❌ Korelasyonsuz
  [ERROR] webhook processing failed
  [ERROR] charge timeout in gateway
  → hangi ödeme?

✓ Payment id ile
  paymentId=8812 step=WebhookReceived error=version_conflict
  paymentId=8812 step=ChargeSent latency_ms=4200
  → aynı ödeme, farklı adımlar, anında görünür
```ट्रेस स्पैन में भुगतान आईडी भी होनी चाहिए। जब आप कोई ट्रेस दर्ज करते हैं, तो आपको चेकआउट से लेकर वेबहुक को अंतिम रूप देने तक के सभी चरण दिखाई देने चाहिए - भले ही विभिन्न सेवाओं के बीच अनुरोध आईडी बदल जाए, भुगतान आईडी स्थिर रहती है।

## चरण ईवेंट लॉग: भुगतान समयरेखा

मेट्रिक्स 'कितने' प्रश्न का उत्तर देते हैं; 'क्या हुआ, क्रम में' प्रश्न पर चरण ईवेंट लॉग। प्रत्येक महत्वपूर्ण कदम एक रिकॉर्ड बनाता है:```text
8812  ChargeRequested      orchestrator   amount=249.00
8812  ChargeSent           gateway        providerRef=ch_abc
8812  SyncResponsePending  orchestrator   redirectUrl=issued
8812  WebhookReceived      gateway        event=PaymentCaptured
8812  FinalizeAttempted    orchestrator   version=3→4
8812  FinalizeSucceeded    orchestrator   status=Captured
```यह केवल लॉग परिशिष्ट है; एक कदम पीछे नहीं हटता, एक नया कदम जुड़ जाता है। मुआवज़ा या सुलह हस्तक्षेप भी अपना कदम स्वयं लिखता है - ताकि इस प्रश्न का उत्तर 'इस भुगतान को दो बार अंतिम रूप क्यों दिया गया' खो न जाए।

स्टेप इवेंट लॉग को ऑडिट ट्रेल के साथ भ्रमित नहीं किया जाना चाहिए: ऑडिट इस प्रश्न का उत्तर देता है कि 'किसने क्या किया'; चरण लॉग 'सिस्टम ने क्या किया, किस क्रम में'। दोनों एक दूसरे के पूरक हैं.

## विलंबित अंतिम मेट्रिक्स: मौन लटकन को दृश्यमान बनाना

`FinalizePending` स्थिति वाला भुगतान PSP पक्ष पर पहले ही संपन्न हो चुका होगा, हालाँकि परिणाम अभी तक ग्राहक को नहीं दिखाया गया है। यह विंडो सामान्य है - लेकिन यह कितने समय तक चलती है, इसे मापा जाना चाहिए।```text
Metrik: deferred_finalize_count
  → şu an FinalizePending'de olan ödeme sayısı

Metrik: deferred_finalize_age_seconds (histogram)
  → her ödemenin bu statüde ne kadar kaldığı

Alert: deferred_finalize_age_p99 > 600s
  → finalize pipeline'ında sistemik sorun
```ये मेट्रिक्स यह भी निर्धारित करते हैं कि सुलह कार्यकर्ता को 'कितनी तत्काल' स्कैन करना चाहिए। यदि `deferred_finalize_age_seconds` बढ़ रहा है, तो समस्या एकल भुगतान के साथ नहीं, बल्कि अंतिम पाइपलाइन या वेबहुक प्रसंस्करण के साथ हो सकती है।

## डैशबोर्ड लेआउट: परिचालन दृश्यता

| पैनल | शो | एक्शन ट्रिगर |
| --- | --- | --- |
| अंतिम गणना स्थगित | स्थापित भुगतान मात्रा | निरंतर वृद्धि → पाइपलाइन समीक्षा |
| आयु को अंतिम रूप दें P99 | सबसे खराब देरी | एसएलए की अधिकता → ऑन-कॉल |
| स्टेप लॉग गैप | गुम चरण (कोई WebhookReceived नहीं) | वेबहुक डिलीवरी समस्या |
| संस्करण संघर्ष दर | दौड़ की तीव्रता | समवर्ती ट्यूनिंग |

## अक्सर भ्रमित होने वाले भेद```text
❌ Request id yeterli korelasyon sağlar
✓ Request id geçicidir; payment id ödeme boyunca kalıcıdır

❌ Log volume = observability
✓ Sorgulanabilir, payment id'li structured log = observability

❌ Metrikler geliştirme için yeterli
✓ Step event log, metriklerin gösteremediği sıra ve bağlamı taşır
```## लॉग बनाम स्टेप इवेंट लॉग बनाम ऑडिट

| शैली | प्रश्न | उदाहरण |
| --- | --- | --- |
| संरचित लॉग | त्वरित घटना विवरण | Webhookप्राप्त, विलंबता=120ms |
| चरण इवेंट लॉग | जीवन चक्र क्रम | चार्ज भेजा गया → वेबहुक प्राप्त → अंतिम रूप |
| ऑडिट लॉग | मानव/प्रक्रिया हस्तक्षेप | ऑपरेटर एक्स ने मैन्युअल हील ट्रिगर किया |

## अवलोकनीयता जांच सूची

1. क्या प्रत्येक लॉग लाइन, ट्रेस स्पैन और मीट्रिक टैग में भुगतान आईडी होती है?
2. क्या चरण ईवेंट लॉग केवल परिशिष्ट है और क्या इसमें प्रत्येक सार्थक चरण शामिल है?
3. क्या `deferred_finalize_count` और `deferred_finalize_age_seconds` मेट्रिक्स परिभाषित हैं?
4. क्या अंतिम आयु P99 के लिए कोई SLA-आधारित अलर्ट है?
5. क्या भुगतान आईडी के साथ चरण लॉग से चेकआउट से टर्मिनल स्थिति तक पूरा पथ पता लगाना संभव है?
6. क्या सुलह कार्यकर्ता द्वारा सही किए गए रिकॉर्ड स्टेप लॉग में लिखे गए हैं?

## इस लेख से आपको क्या याद रखना चाहिए

1. भुगतान आईडी सभी अवलोकन की रीढ़ है; अकेले अनुरोध आईडी पर्याप्त नहीं है.
2. स्टेप इवेंट लॉग भुगतान की समयरेखा है; इसमें वह क्रम है जो मेट्रिक्स नहीं दिखा सकते।
3. आस्थगित अंतिम मेट्रिक्स शांत घूमने को मापा और उत्तेजक बनाते हैं।
4. अवलोकनशीलता कोई विलासिता नहीं है; यह निर्धारित करता है कि सुलह और ऑन-कॉल क्या चाहते हैं।

> जब कोई भुगतान अटक जाता है, तो 'आइए लॉग देखें' पर्याप्त नहीं है; आपको एक चरण ईवेंट लॉग और एक स्थगित अंतिम मीट्रिक की आवश्यकता है जो भुगतान आईडी के साथ सेकंड के भीतर दिखाएगा कि आप किस चरण में हैं।

अगले भाग में हम इस दृश्यता के शीर्ष पर पुनर्प्राप्ति पाइपलाइन और रनबुक बनाते हैं: पहले स्वचालन, विशिष्टता की दीवारों के भीतर मानवीय हस्तक्षेप।