प्लेबुक
भुगतान का प्रमाण और भुगतान की स्थिति: आपको भ्रमित क्यों नहीं होना चाहिए (Payment Evidence Vs Payment State)
सबूत वही है जो पीएसपी कहता है। राज्य वही है जो आप तय करते हैं। यदि आप इन दोनों को एक ही रजिस्ट्री में रखते हैं, तो आपको पता चल जाएगा कि पुनर्प्राप्ति के दौरान किस पर भरोसा करना है।
वितरित भुगतान इंजन
भाग 8 का 22
वितरित भुगतान आर्किटेक्चर की एक श्रृंखला जो कैप्चर और पूर्ण के बीच के अंतर को पाटती है।
दो अलग-अलग प्रश्न, दो अलग-अलग रिकॉर्ड
"पीएसपी ने क्या कहा?" और "हमने क्या निर्णय लिया?" ये दो समान लेकिन वास्तव में पूरी तरह से अलग प्रश्न हैं। पहले का उत्तर साक्ष्य है: पीएसपी से कच्चा वेबहुक, एपीआई प्रतिक्रिया, टाइमस्टैम्प - एक अपरिवर्तनीय रिकॉर्ड। दूसरे का उत्तर यह है: इस साक्ष्य और अपने व्यावसायिक नियमों को मिलाकर आप जो निर्णय लेते हैं - भुगतान Captured या चेकआउट Completed।```text
Evidence (kanıt) State (durum)
PSP'nin ham cevabı → Sizin kararınız
Değişmez, append-only → Değişebilir, karar tablosu
“Ne oldu” → “Biz ne yaptık”
## पहले उल्लेख पर अवधारणाएँ```text
📦 Evidence (Kanıt)
Dış sistemin (PSP) size bildirdiği ham gerçeğin, yorumlanmadan ve değiştirilmeden saklanan kaydı.
📦 State (Durum)
Evidence'ları ve iş kurallarını birleştirerek sizin verdiğiniz, ikinci ve dördüncü bölümde tanımladığımız durum makinesindeki karar.
📦 Append-only Log
Sadece ekleme yapılan, mevcut kayıtların asla üzerine yazılmadığı veya silinmediği depolama şekli.
📦 Source of Truth vs. Derived Truth
Birincisi ham, tartışmasız gerçek; ikincisi bu gerçekten türetilen, yorum içeren karar.
📦 Reconciliation
Evidence kayıtlarını tekrar okuyup, mevcut state'in bu kanıtlarla hâlâ tutarlı olup olmadığını doğrulama süreci.
```इस अंतर को सबसे स्पष्ट रूप से प्रदर्शित करने वाला उदाहरण यह है: पीएसपी द्वारा भेजा गया वेबहुक पेलोड साक्ष्य है; यह राज्य का निर्णय है कि आप इस पेलोड को पढ़ें और `Payment.Status = Captured` लिखें। साक्ष्य कभी नहीं बदलता; नए साक्ष्य आने पर राज्य को अपडेट किया जा सकता है।
## ये दोनों एक ही टेबल पर क्यों नहीं रह सकते
कुछ सिस्टम PSP से आने वाले वेबहुक के साथ `payments` तालिका को सीधे अधिलेखित कर देते हैं: जब एक नया वेबहुक आता है, तो संबंधित पंक्ति अपडेट हो जाती है, पुराना मान खो जाता है। इस डिज़ाइन के साथ, अब आप इस प्रश्न का उत्तर नहीं दे सकते कि "पीएसपी ने वास्तव में क्या कहा" - आप केवल इस प्रश्न का उत्तर दे सकते हैं कि "हमारी अंतिम टिप्पणी क्या थी?"```text
Yanlış model:
payments
id | status | raw_payload
1 | Captured | {...son webhook'un içeriği, öncekiler üzerine yazıldı...}
```इसका मतलब है कि आप वह जानकारी (साक्ष्य की पिछली श्रृंखला) खो देते हैं जो किसी घटना के दौरान सबसे उपयोगी होगी।
## सही मॉडल: दो अलग भंडारण
साक्ष्य अपनी स्वयं की परिशिष्ट-तालिका में संग्रहीत है; प्रत्येक नई वेबहुक या एपीआई प्रतिक्रिया को एक नई लाइन के रूप में जोड़ा जाता है, कोई भी लाइन अपडेट या हटाई नहीं जाती है। राज्य एक अलग तालिका में साक्ष्य से प्राप्त वर्तमान निर्णय है।```text
payment_evidence (append-only)
id | payment_id | source | received_at | raw_payload
1 | pay_42 | psp | t1 | {...authorize...}
2 | pay_42 | psp | t2 | {...captured...}
3 | pay_42 | psp | t5 | {...captured (duplicate)...}
payments (state)
id | status
pay_42 | Captured ← evidence #2'den türetildi, #3 aynı sonucu doğruladı
```इस अंतर के कारण, राज्य रेखा कभी नहीं भूलती कि वह कब और क्यों बदली - क्योंकि इसे उत्पन्न करने वाले साक्ष्य अभी भी मौजूद हैं।
## पुनर्प्राप्ति साक्ष्य क्यों पढ़ती है, बयान क्यों नहीं?
जब आपको किसी घटना के बाद अपने सिस्टम को "सही" स्थिति में वापस लाने की आवश्यकता होती है (उदाहरण के लिए, एक कर्मचारी दुर्घटना, एक गलत तैनाती, एक संदिग्ध असंगतता), तो वर्तमान स्थिति पर भरोसा करना जोखिम भरा होता है - क्योंकि स्थिति बिल्कुल वैसी ही हो सकती है जैसी घटना हुई थी। इसके बजाय, साक्ष्य लॉग को दोबारा पढ़ना और स्थिति को दोबारा चलाना पुनर्प्राप्ति का अधिक विश्वसनीय तरीका है।```text
Recovery süreci
1. payment_evidence tablosundan pay_42'ye ait tüm kayıtları zaman sırasına göre oku
2. Her evidence'ı iş kurallarına göre tekrar işle (guard'lardan geçir)
3. Sonuçta türeyen state'i mevcut payments tablosundaki değerle karşılaştır
4. Fark varsa, hangisi doğru olduğunu evidence'a dayanarak belirle — state'e değil
```यह प्रक्रिया सुलह कार्यकर्ताओं का आधार बनती है जिसे हम इस श्रृंखला में बाद में कवर करेंगे: जब राज्य संदेह में होता है, तो साक्ष्य हमेशा मध्यस्थ होता है।
## कभी भी "व्याख्यायित" साक्ष्य संग्रहित न करें
एक आखिरी ख़तरा: यहां तक कि जब कुछ सिस्टम साक्ष्य संग्रहीत करते हैं, तो वे इसे थोड़ा "साफ़" करते हैं - अनावश्यक फ़ील्ड हटाते हैं, प्रारूप को सामान्य करते हैं। इससे साक्ष्य का वास्तविक मूल्य खो जाता है (पीएसपी ने वास्तव में क्या कहा, बाइट दर बाइट)। साक्ष्य आपके लिए पीएसपी के उत्तर का कच्चा, अपरिवर्तित संस्करण होना चाहिए; व्याख्या और सामान्यीकरण का कार्य राज्य व्युत्पत्ति चरण का है, साक्ष्य का नहीं।
## इस एपिसोड में सबसे भ्रमित करने वाला मैचअप```text
❌ Evidence ve state aynı satırda tutulabilir, biri diğerinin üzerine yazılabilir
✓ Evidence append-only'dir; state ayrı bir tabloda, evidence'tan türetilir
❌ Webhook payload'ını saklamadan önce “temizlemek” zararsızdır
✓ Temizlenmiş evidence, PSP'nin tam olarak ne söylediği bilgisini kaybettirir
❌ Bir incident'te mevcut state'e güvenip devam etmek en hızlı yoldur
✓ Incident sırasında state şüphelidir; evidence'tan yeniden türetmek (replay) daha güvenilirdir
❌ Evidence sadece debug/log amaçlıdır, iş kararı için gerekli değildir
✓ Evidence, reconciliation ve recovery'nin tek güvenilir kaynağıdır
आपके साक्ष्य/राज्य भेद के लिए चेकलिस्ट
- क्या PSP से कच्चा वेबहुक पेलोड एक अलग, केवल-परिशिष्ट तालिका में संग्रहीत है, या इसे
paymentsतालिका द्वारा अधिलेखित किया गया है? - क्या उसी भुगतान के लिए दूसरा या तीसरा वेबहुक पहले रिकॉर्ड को अधिलेखित कर देता है या एक नई साक्ष्य पंक्ति जोड़ दी जाती है?
- जब राज्य की असंगति का संदेह हो, तो क्या आपके पास ऐसी प्रक्रिया है जो साक्ष्य लॉग को दोबारा चला सके?
- क्या साक्ष्य संग्रहीत करते समय कोई "सफाई" या सामान्यीकरण कदम हैं? यदि हां, तो क्या आप कच्चा डेटा भी अलग से संग्रहीत करते हैं?
- क्या आप पूर्वव्यापी रूप से पता लगा सकते हैं कि आपकी राज्य तालिका में एक पंक्ति किस साक्ष्य रिकॉर्ड से ली गई है?
यदि आप इन पांच प्रश्नों में से किसी एक का उत्तर "नहीं" देते हैं, तो आप किसी घटना में "पीएसपी ने वास्तव में क्या कहा" प्रश्न का उत्तर देने में सक्षम नहीं हो सकते हैं।
इस अनुभाग से याद रखने योग्य बातें
- साक्ष्य वह कच्चा और अपरिवर्तनीय सत्य है जो पीएसपी आपको बताता है; राज्य वह निर्णय है जो आप इन तथ्यों को व्यावसायिक नियमों के साथ जोड़कर लेते हैं।
- साक्ष्य केवल संलग्न होना चाहिए; जब कोई नया वेबहुक आता है, तो पुराने को ओवरराइट नहीं किया जाता, एक नई लाइन जोड़ दी जाती है।
- पुनर्प्राप्ति और समाधान प्रक्रियाओं को वर्तमान स्थिति पर निर्भर नहीं होना चाहिए; साक्ष्य लॉग को दोबारा अवश्य पढ़ें और स्थिति प्राप्त करें।
- "सफाई" साक्ष्य को छुपाने पर आप यह ज्ञान खो देते हैं कि पीएसपी ने वास्तव में क्या कहा था; कच्चे डेटा को हमेशा सुरक्षित रखा जाना चाहिए।
राज्य आज आपकी टिप्पणी है; सबूत वह गवाह है जो कभी नहीं बदलता। यदि आप किसी घटना के गवाह के बजाय अपनी ही व्याख्या पर सवाल उठाने लगेंगे तो आप हार जायेंगे।
FAQ
Frequently asked questions
साक्ष्य क्या है?
अपरिष्कृत सत्य का एक रिकॉर्ड जो बाहरी सिस्टम (पीएसपी) आपको रिपोर्ट करता है, बिना किसी व्याख्या या संशोधन के संग्रहीत किया जाता है।
राज्य क्या है?
राज्य मशीन में साक्ष्य और व्यावसायिक नियमों को मिलाकर आप जो निर्णय लेते हैं उसका वर्णन हमने अध्याय दो और चार में किया है।
क्या यह सच है कि "साक्ष्य और राज्य को एक ही पंक्ति में रखा जा सकता है, एक दूसरे को ओवरराइट कर रहा है"?
साक्ष्य केवल परिशिष्ट है; राज्य को एक अलग तालिका में साक्ष्य से प्राप्त किया गया है
यह अनुभाग क्या ठीक करता है?
यह अनुभाग बताता है कि आपको दोनों को एक ही लॉग में क्यों नहीं रखना चाहिए और यह अंतर बचाव परिदृश्यों में जीवन क्यों बचाता है। साक्ष्य वह कच्चा, अपरिवर्तनीय सत्य है जो पीएसपी आपको बताता है; राज्य वह निर्णय है जो आप इन तथ्यों को व्यावसायिक नियमों के साथ जोड़कर लेते हैं। "पीएसपी ने क्या कहा?" और "हमने क्या निर्णय लिया?" ये दो समान लेकिन वास्तव में पूरी तरह से अलग प्रश्न हैं। पहले का उत्तर साक्ष्य है: पीएसपी से कच्चा वेबहुक, एपीआई प्रतिक्रिया, टाइमस्टैम्प - एक अपरिवर्तनीय रिकॉर्ड। दूसरे का उत्तर यह है: इस साक्ष्य और अपने व्यावसायिक नियमों को मिलाकर आप जो निर्णय लेते हैं - भुगतान `Captured` या चेकआउट `Completed`।
इंजीनियरिंग सिद्धांत सीखे गए
- साक्ष्य पीएसपी का कच्चा और अपरिवर्तनीय सत्य है; राज्य वह निर्णय है जो आप उस तथ्य को व्यावसायिक नियमों के साथ जोड़कर लेते हैं - दोनों एक ही रिकॉर्ड नहीं हैं।
- साक्ष्य हमेशा केवल संलग्न होना चाहिए; नई जानकारी को अधिलेखित नहीं किया जाता बल्कि पुरानी जानकारी में जोड़ दिया जाता है।
- बचाव और मेल-मिलाप हमेशा अपरिवर्तनीय साक्ष्य पर निर्भर होना चाहिए, संदिग्ध स्थिति पर नहीं।
जारी रखें पढ़ रहे हैं
जारी रखें पढ़ रहे हैं
श्रृंखला में अगला
एसडीके (सॉफ्टवेयर डेवलपमेंट किट) लीक किए बिना प्रदाता अमूर्त: गेटवे की सीमा
प्रदाता गेटवे पीएसपी एसडीके का मालिक कैसे है, चेकआउट ऑर्केस्ट्रेटर को केवल सिमेंटिक इंटरफ़ेस क्यों देखना चाहिए? कार्ड और वॉलेट प्रवाह अलग-अलग हैं...
श्रृंखला में अगला
भुगतान प्रणालियों में आउटबॉक्स/इनबॉक्स पैटर्न
यदि डेटाबेस में लिखना और किसी ईवेंट को प्रकाशित करना एक ही लेनदेन में नहीं है, तो उनमें से एक खो जाएगा या दोहराया जाएगा। आउटबॉक्स प्रसारण, इनबॉक्स उपभोक्ता…
वही सिलसिला
रॉ प्रदाता डेटा के बजाय सिमेंटिक इवेंट
क्या प्रदाता गेटवे द्वारा प्राप्त वेबहुक को पीएसपी के इवेंट नाम या पेमेंटकैप्चर्ड/पेमेंटफ़ेल्ड जैसे सिमेंटिक इवेंट के साथ डाउनस्ट्रीम तक पहुंचना चाहिए?