प्रभावी ढंग से-एक बार भुगतान की प्रक्रिया (Effectively Once Processing In Payments)

पिछले अनुभाग में, हमने देखा कि पुनर्प्राप्ति पाइपलाइन पहले स्वचालन के सिद्धांत पर काम करती है और साक्ष्य-आधारित रनबुक विशिष्टता दीवारों में काम आती है। यह अनुभाग पाइपलाइन के अंतर्गत आने वाली मैसेजिंग गारंटी पर प्रकाश डालता है - और उद्योग की सबसे आम ग़लतफ़हमी: बिल्कुल एक बार डिलीवरी।

ब्रोकर विक्रेता 'बिल्कुल-एक बार शब्दार्थ' का वादा करते हैं। तथ्य यह है कि एक वितरित प्रणाली में यह भौतिक रूप से गारंटी नहीं है कि एक संदेश ठीक एक बार संसाधित किया जाएगा। नेटवर्क ख़राब हो जाता है, कर्मचारी क्रैश हो जाता है, ब्रोकर दोबारा भेजता है। सवाल यह नहीं है कि 'संदेश कितनी बार आया'; कार्य परिणाम कितनी बार आया।```text Exactly-once messaging → imkansız (at-least-once + failure = duplicate) Effectively-once outcome → mümkün (defense in depth)

## पहले उल्लेख पर अवधारणाएँ```text
📦 At-Least-Once Delivery
Mesaj en az bir kez ulaşır; ağ hatasında tekrar gönderilebilir.

📦 Effectively-Once
Mesaj birden fazla kez işlense bile iş sonucu (charge, refund, order) yalnızca bir kez gerçekleşir.

📦 Defense in Depth
Tek bir mekanizmaya güvenmek yerine, birden fazla bağımsız koruma katmanı.

📦 Idempotent Consumer
Aynı mesajı ikinci kez aldığında aynı sonucu üreten, yan etki yaratmayan tüketici.
```सटीक रूप से-एक बार मैसेजिंग ब्रोकर सुविधा नहीं है; यह एक प्रभावी ढंग से पहला सिस्टम डिज़ाइन है।

## बिल्कुल-एक बार झूठ क्यों बोलना

एक कार्यकर्ता संदेश प्राप्त करता है, उसे संसाधित करता है, एक पावती भेजता है - लेकिन पावती नेटवर्क में खो जाती है। ब्रोकर संदेश दोबारा भेजता है। कार्यकर्ता दूसरी बार प्रक्रिया करता है. यह कम से कम एक बार डिलीवरी की प्रकृति है; इससे कोई फर्क नहीं पड़ता कि ब्रोकर कितना 'बिल्कुल-एक बार' दावा करता है, उपभोक्ता पक्ष पर दोहराव अपरिहार्य है।```text
Worker mesajı işler → sonuç: Captured
Ack ağda kaybolur
Broker mesajı tekrar gönderir
Worker tekrar işler → sonuç: ??? (çift charge riski)
```मुद्दा यह नहीं है कि संदेश कितनी बार आता है; दूसरे आगमन पर यही होता है। यदि दूसरी बार के दौरे पर कोई दुष्प्रभाव नहीं होता है, तो इसका मतलब है कि इसे प्रभावी ढंग से प्राप्त किया गया है- एक बार।

## गहराई में बचाव: एक परत पर्याप्त नहीं है

प्रभावी रूप से, व्यावसायिक परिणाम पूरक परतों का एक संयोजन है। न तो अकेला पर्याप्त है; सभी मिलकर परिणाम देते हैं 'जो संदेश कम से कम एक बार आता है उसका प्रभाव अधिकतम एक बार ही होता है।'```text
Katman 1: Idempotency key (API)
  → aynı key ile ikinci charge isteği reddedilir

Katman 2: Consumer dedup (messaging)
  → aynı message id ikinci kez işlenmez

Katman 3: DB uniqueness constraint
  → aynı idempotency key ile ikinci satır yazılamaz

Katman 4: Outbox pattern
  → event yalnızca transaction commit ile birlikte yayınlanır

Katman 5: Reconciliation
  → katman 1-4'ün kaçırdığı drift'i periyodik olarak düzeltir
```यदि एक परत विफल हो जाती है, तो दूसरी उसकी जगह ले लेती है। यदि निष्क्रियता कुंजी को छोड़ दिया जाता है, तो विशिष्टता बाधा पकड़ में आ जाती है; यदि बाधा हटा दी जाए तो सुलह ठीक हो जाती है।

## प्रत्येक परत के लिए प्रश्न अलग है

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

##बेवकूफ उपभोक्ता कैसे लिखें

निष्क्रिय उपभोक्ता का नियम: समान इनपुट, समान आउटपुट; दूसरी कॉल पर कोई दुष्प्रभाव नहीं।```text
PaymentCaptured webhook (messageId=wh_991)
  → dedup tablosuna bak: wh_991 işlendi mi?
  → evet → skip (log: duplicate suppressed)
  → hayır → finalize, dedup tablosuna yaz
```अंतिम चरण स्वयं निरर्थक होना चाहिए: यदि भुगतान पहले से ही `Captured` है, तो कोई ईवेंट दोबारा जारी नहीं किया जाना चाहिए, कोई ऑर्डर दोबारा नहीं बनाया जाना चाहिए। डेडअप तालिका मैसेजिंग परत को सुरक्षित रखती है; टर्मिनल स्थिति नियंत्रण व्यावसायिक तर्क की सुरक्षा करता है।

## आउटबॉक्स: घटना और स्थिति एक ही लेनदेन में हैं

आउटबॉक्स पैटर्न 'स्थिति अपडेट की गई लेकिन ईवेंट प्रकाशित नहीं हुआ' या 'ईवेंट प्रकाशित हुआ लेकिन स्थिति अपडेट नहीं हुई' दुविधा को हल करता है। इवेंट को स्थानीय लेनदेन के साथ आउटबॉक्स तालिका में लिखा जाता है; एक अलग प्रकाशक आउटबॉक्स को पढ़ता है और ब्रोकर को भेजता है।```text
BEGIN TRANSACTION
  UPDATE payment SET status=Captured
  INSERT INTO outbox (event=PaymentCaptured, paymentId=8812)
COMMIT
  → publisher outbox'ı okur → broker'a gönderir
  → gönderim başarılı → outbox satırını siler
```आउटबॉक्स बिल्कुल एक बार मैसेजिंग प्रदान नहीं करता है - लेकिन यह स्थिति और घटना के बीच स्थिरता सुनिश्चित करता है। सुलह उन लोगों को पकड़ लेती है जो आउटबॉक्स से भाग गए हैं।

## अक्सर भ्रमित होने वाले भेद```text
❌ Broker exactly-once = sistem exactly-once
✓ Broker dedup + consumer idempotency + DB constraint = effectively-once

❌ Idempotency key her yerde yeterli
✓ Idempotency key API'yi korur; webhook ve async worker ayrı katman ister

❌ Effectively-once = perfect system
✓ Effectively-once = iş sonucu bir kez; tutarsızlık penceresi reconciliation ile kapanır
```## डिलिवरी गारंटी बनाम व्यावसायिक परिणाम

| वारंटी | यह क्या वादा करता है? क्या यह भुगतान के लिए पर्याप्त है? |
| --- | --- | --- |
| अधिक से अधिक एक बार | एक बार संदेश खो जाने पर वह खो सकता है | नहीं - भुगतान खो गया |
| कम से कम एक बार | संदेश को कम से कम एक बार डुप्लिकेट किया जा सकता है | नहीं - अकेले |
| बिल्कुल-एक बार (दलाल) | सैद्धांतिक रूप से, व्यावहारिक रूप से यह उपभोक्ता पक्ष पर टूटता है | नहीं |
| प्रभावी रूप से-एक बार (सिस्टम) | नौकरी का रिजल्ट एक बार | हाँ |

## प्रभावी ढंग से-एक बार चेकलिस्ट

1. क्या एपीआई शुल्क अनुरोध इडेम्पोटेंसी कुंजी से सुरक्षित हैं?
2. क्या वेबहुक और एसिंक उपभोक्ताओं में संदेश-आईडी कटौती है?
3. क्या भुगतान तालिका में निष्क्रियता कुंजी पर कोई विशिष्टता बाधा है?
4. क्या राज्य परिवर्तन और घटना का प्रसारण आउटबॉक्स पैटर्न के समान लेनदेन में होता है?
5. क्या अंतिम रूप देने वाला हैंडलर टर्मिनल स्थिति में पुनः संचालन किए बिना छोड़ देता है?
6. क्या रिकॉन्सिलिएशन समय-समय पर परतों 1-5 से छूटे बहाव के लिए स्कैन करता है?

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

1. बिल्कुल-एक बार मैसेज करना झूठ है; कम से कम एक बार + विफलता = नकल अपरिहार्य है।
2. प्रभावी ढंग से - एक बार गहराई से रक्षा के साथ व्यावसायिक परिणाम संभव है - एक परत पर्याप्त नहीं है।
3. सुरक्षा की प्रत्येक परत एक अलग प्रश्न का उत्तर देती है; उन सभी को एक साथ मिलकर काम करना चाहिए।
4. सुलह आखिरी परत है; यह पिछली परतों का पूरक है, प्रतिस्थापित नहीं।

> भले ही आपका ब्रोकर बिल्कुल एक बार वादा करता है, आपकी भुगतान प्रणाली को इस पर विश्वास नहीं करना चाहिए - उसे जो विश्वास करना चाहिए वह व्यवसाय के परिणाम को गहराई से प्रभावी ढंग से तैयार करना है।

अगले भाग में, हम इस 22-भाग की यात्रा के संश्लेषण की ओर बढ़ते हैं: उत्पादन भुगतान इंजन डिज़ाइन चेकलिस्ट।