एक उत्पादन भुगतान इंजन डिजाइन करना (Designing A Production Payment Engine)

यह श्रृंखला प्रदाता अमूर्तता के साथ शुरू हुई और वेबहुक विश्वसनीयता, निष्क्रियता, गाथा, पट्टा, आम सहमति, अवलोकन, पुनर्प्राप्ति पाइपलाइन और प्रभावी ढंग से एक बार प्रसंस्करण तक चली गई। यह अंतिम तकनीकी खंड उस यात्रा का संश्लेषण है: यदि आप एक भुगतान इंजन डिज़ाइन कर रहे हैं जो उत्पादन में चलता है, तो आपको कौन से निर्णय लेने चाहिए और किस क्रम में लेना चाहिए?

चेकलिस्ट सुविधाओं की सूची नहीं है. प्रत्येक आइटम श्रृंखला के एक या अधिक भागों में प्रतिपादित सिद्धांत का मापने योग्य परीक्षण है। यह 'क्या कोई निष्क्रियता है?' सवाल यह है कि 'क्या इडेम्पोटेंसी कुंजी एपीआई, वेबहुक डिडअप और डीबी यूनिकनेस तिकड़ी एक साथ काम करती है?'```text Production Payment Engine ├─ Boundaries (orchestrator ↔ gateway) ├─ State & Evidence ├─ Reliability (retry, lease, outbox) ├─ Recovery (reconciliation, runbooks) └─ Observability (payment id, step log, metrics)

## पहले उल्लेख पर अवधारणाएँ```text
📦 Checkout Orchestrator
Ödeme niyetini yöneten, semantik sonuç gören, PSP detayı bilmeyen servis.

📦 Provider Gateway
PSP SDK'sını, webhook çevirisini ve provider'a özgü akışları sahiplenen servis.

📦 Production Readiness
Sistemin sadece happy path'te değil, arıza, yarış ve sürüklenme anlarında da doğru davranması.

📦 Architectural Checklist
Tasarım kararlarının ölçülebilir, evet/hayır testlerine dönüştürülmüş hali.
```उत्पादन भुगतान इंजन का मतलब यह नहीं है कि 'चार्ज एपीआई काम कर रहा है'; यह इस प्रश्न का उत्तर देना है कि 'क्या होता है जब चार्ज विफल हो जाता है, वेबहुक देर से आता है, कर्मचारी दुर्घटनाग्रस्त हो जाता है?'

## 1. सीमाएं: कोई एसडीके लीक नहीं

- [ ] क्या चेकआउट ऑर्केस्ट्रेटर किसी भी पीएसपी एसडीके प्रकार का आयात नहीं करता है?
- [ ] क्या ऑर्केस्ट्रेटर केवल सिमेंटिक `ChargeRequest` / `ChargeResult` देखता है?
- [ ] क्या वेबहुक कच्चे प्रदाता पेलोड के रूप में या सिमेंटिक इवेंट के रूप में डाउनस्ट्रीम तक पहुंचता है?
- [ ] क्या प्रदाता गेटवे प्रदाता इवेंट → सिमेंटिक इवेंट मैपिंग टेबल का एकमात्र मालिक है?
- [ ] क्या नए पीएसपी को जोड़ने के लिए ऑर्केस्ट्रेटर कोड में शून्य परिवर्तन की आवश्यकता होती है?

यह एपिसोड सीरीज का 9-10वां एपिसोड है। इसके भागों का सार है. यदि सीमा टूट जाती है, तो प्रत्येक शेष परत उस रिसाव के ऊपर बनाई जाती है।

## 2. कथन एवं साक्ष्य: कथन ≠ प्रमाण

- [ ] क्या भुगतान स्थिति मशीन स्पष्ट रूप से परिभाषित है (प्रसंस्करण, अंतिम रूप देना लंबित, कैप्चर किया गया, विफल, समाप्त)?
- [ ] क्या टर्मिनल स्थितियाँ अपरिवर्तनीय हैं?
- [ ] क्या भुगतान स्नैपशॉट (राशि, मुद्रा, टोकरी) अपरिवर्तनीय है?
- [ ] क्या पीएसपी से साक्ष्य (वेबहुक, सिंक प्रतिक्रिया) एक अलग साक्ष्य तालिका में संग्रहीत है?
- [ ] क्या राज्य परिवर्तन साक्ष्य या धारणा पर आधारित हैं?

## 3. विश्वसनीयता: पुनः प्रयास करें, लीज करें, आउटबॉक्स करें

- [ ] क्या त्रुटि वर्गीकरण को परिभाषित किया गया है (बिजनेस डिक्लाइन, टाइमआउट, रेटलिमिटेड, इंफ्रास्ट्रक्चर)?
- [ ] क्या प्रत्येक श्रेणी के लिए एक अलग पुनः प्रयास नीति लागू की गई है?
- [ ] क्या डीबी-समर्थित नौकरियां पट्टे के तहत संसाधित की जाती हैं?
- [ ] क्या वेबहुक हैंडलर लीज + वर्जन टोकन का एक साथ उपयोग कर रहा है?
- [ ] क्या घटना राज्य परिवर्तन के साथ आउटबॉक्स पैटर्न के समान लेनदेन में है?
- [ ] क्या इडेम्पोटेंसी कुंजी एपीआई, उपभोक्ता डिडअप और डीबी विशिष्टता की तिकड़ी एक साथ है?

## 4. पुनर्प्राप्ति: स्वचालन पहले, रनबुक बाद में

- [ ] क्या सुलह सफाई कर्मचारी अंतिम रूप से लंबित / समाप्त हो चुके रिकॉर्ड को स्कैन करता है?
- [ ] क्या अनाथ शुल्क परिदृश्य को सहसंबंध आईडी के साथ हल किया जा सकता है?
- [ ] क्या मल्टी-इंटेंट कार्ट के लिए कार्ट लॉकिंग है?
- [ ] क्या यूनिकनेस वॉल मैनुअल समीक्षा कतार में लिखता है?- [ ] क्या रनबुक साक्ष्य-आधारित (स्टेप लॉग + पीएसपी क्वेरी + ऑडिट) है?
- [ ] क्या उपचार/धनवापसी का निर्णय एक प्रक्रिया है, प्रतिक्रिया नहीं?

## 5. अवलोकनीयता: भुगतान आईडी रीढ़

- [ ] क्या प्रत्येक लॉग, ट्रेस और मीट्रिक में भुगतान आईडी होती है?
- [ ] क्या चरण ईवेंट लॉग केवल परिशिष्ट है और क्या यह प्रत्येक सार्थक चरण को कवर करता है?
- [ ] क्या `deferred_finalize_count` और `deferred_finalize_age_seconds` मेट्रिक्स परिभाषित हैं?
- [ ] क्या ड्रिफ्ट गिनती अचानक बढ़ने पर अलर्ट उत्पन्न करती है?
- [ ] क्या भुगतान आईडी के साथ चेकआउट से टर्मिनल स्थिति तक का पूरा रास्ता ट्रैक करना संभव है?

## 6. संगति मॉडल: अंतिम, मध्यम, अवलोकनीय

- [ ] क्या सागा+सुलह मॉडल को 2पीसी के बजाय जानबूझकर चुना गया था?
- [ ] क्या प्रत्येक गाथा चरण की क्षतिपूर्ति कार्रवाई परिभाषित है?
- [ ] क्या अंतिम स्थिरता विंडो को मापा जाता है और उत्पाद टीम के साथ साझा किया जाता है?
- [ ] क्या 'हर समय एकरस' के भ्रम के बजाय 'थोड़े समय में एकसमान' होने का लक्ष्य है?```text
Checklist tamamlandığında sorulacak son soru:
  'Bu sistemin en kötü gününde ne olur?'
  → Cevap runbook'ta, metriklerde ve reconciliation'da yazılı olmalı.

अक्सर भ्रमित होने वाले भेद```text

❌ Checklist = feature tamamlandı demek ✓ Checklist = mimari ilkenin ölçülebilir testi

❌ Production ready = load test geçti ✓ Production ready = arıza anında doğru davranış kanıtlandı

❌ Daha fazla PSP = daha fazla karmaşıklık ✓ İyi sınırlar varsa, yeni PSP yalnızca gateway'i etkiler

| धारा | श्रृंखला के एपिसोड | मूल प्रश्न |
| --- | --- | --- |
| सीमाएँ | 9-10 | क्या ऑर्केस्ट्रेटर पीएसपी जानता है? |
| स्थिति एवं साक्ष्य | 1-4, 6 | क्या यह राज्य के साक्ष्य पर आधारित है? |
| विश्वसनीयता | 5, 7-8, 11, 17, 20 | खराबी की स्थिति में क्या होता है? |
| पुनर्प्राप्ति | 12-16, 19 | बहाव कैसे पकड़ें? |
| अवलोकनीयता | 18 | क्या रुकी हुई पेमेंट दिख रही है? |
| संगति | 3, 16 | 2पीसी या सागा? |

## उत्पादन तत्परता का आकलन

1. डिज़ाइन समीक्षा में चेकलिस्ट के छह अनुभागों को एक-एक करके देखें; प्रत्येक आइटम के लिए हाँ/नहीं/आंशिक रूप से उत्तर दें।
2. तकनीकी ऋण सूची में 'आंशिक' उत्तर जोड़ें; व्यावसायिक प्रभाव के आधार पर प्राथमिकता दें।
3. सबसे खराब दिन की स्थिति (PSP 5xx, वेबहुक लैग, वर्कर क्रैश, ऑर्फ़न चार्ज) को टेबलटॉप अभ्यास के रूप में चलाएँ।
4. ध्यान दें कि अभ्यास के दौरान कौन से चेकलिस्ट आइटम खाली रहते हैं - ये प्रारंभिक सुधार लक्ष्य हैं।
5. चेकलिस्ट को एक जीवित दस्तावेज़ के रूप में रखें; प्रत्येक उत्पादन घटना के बाद प्रासंगिक लेख को अद्यतन करें।

## इस शृंखला से क्या याद रखना चाहिए

1. उत्पादन भुगतान इंजन को विफलता व्यवहार से मापा जाता है, खुश पथ से नहीं।
2. चेकलिस्ट श्रृंखला के 22 एपिसोड का एक मापने योग्य संश्लेषण है - फीचर सूची नहीं।
3. यदि सीमाएं (ऑर्केस्ट्रेटर ↔ गेटवे) टूट गई हैं, तो बाकी सब कुछ उस रिसाव के ऊपर बनाया गया है।
4. सबसे खराब दिन वाले प्रश्न का उत्तर रनबुक, मेट्रिक्स और रिकंसिलेशन में लिखा जाना चाहिए।

> उत्पादन भुगतान इंजन को डिज़ाइन करना 'चार्ज एपीआई लिखने' के बारे में नहीं है - यह कैप्चर और पूर्ण नियंत्रित, अवलोकन योग्य और पुनर्प्राप्ति योग्य के बीच अंतर बनाने के बारे में है।

अंतिम एपिसोड में, हम श्रृंखला को कैरियर के परिप्रेक्ष्य में ले जाते हैं: फिनटेक कंपनियां वास्तव में क्या तलाश रही हैं?