भुगतान प्रणालियों में आउटबॉक्स/इनबॉक्स पैटर्न (Outbox Inbox Pattern In Payment Systems)

दो लिखते हैं, एक लेन-देन नहीं

जब कोई सेवा "आदेश दिया गया" का निर्णय लेती है तो वह आम तौर पर दो काम करना चाहती है: डेटाबेस में एक पंक्ति लिखना और एक संदेश कतार/दलाल पर एक घटना प्रकाशित करना। चूंकि ये दोनों लेख अलग-अलग प्रणालियों पर जाते हैं, इसलिए इन्हें एक ही लेनदेन में परमाणु रूप से नहीं किया जा सकता है। उनके बीच की जगह को "डुअल-राइट होल" कहा जाता है।```text DbContext.SaveChanges() → veritabanına yazıldı Broker.Publish(event) → burası başarısız olursa event kaybolur (veya sıra tersine çevrilirse, event gönderilir ama DB commit rollback olur)

## पहले उल्लेख पर अवधारणाएँ```text
📦 Dual-Write Problemi
Aynı iş kararının iki farklı sisteme (DB ve broker) atomik olmayan iki yazma ile yansıtılmaya çalışılması.

📦 Outbox
İş kararıyla aynı veritabanı transaction'ında yazılan, sonradan ayrı bir süreç tarafından yayınlanan olay tablosu.

📦 Lease
Bir publisher sürecinin, outbox'taki bir satırı işlerken diğer publisher süreçlerinin aynı satırı almasını önleyen geçici kilit.

📦 Inbox
Tüketici tarafında, gelen bir olayın işlenmeden önce kaydedildiği ve tekrarları filtreleyen tablo.

📦 Effectively-once
At-least-once teslimat ile idempotent tüketicinin birleşiminden elde edilen, pratikte “tam olarak bir kez” gibi davranan sonuç.
```आउटबॉक्स भेजने वाले पक्ष की समस्या (लिखें + प्रसारण परमाणुता) को हल करता है। इनबॉक्स प्राप्तकर्ता पक्ष की समस्या (पुनः डिलीवरी) का समाधान करता है। साथ में, वे एक विश्वसनीय एंड-टू-एंड इवेंट प्रवाह स्थापित करते हैं।

## डुअल-राइट होल कैसे खोलें

यदि कोई हैंडलर डेटाबेस पर लिखने के तुरंत बाद ब्रोकर को कोई ईवेंट जारी करता है, तो सिस्टम दो अलग-अलग चरणों के बीच क्रैश हो सकता है। यदि डीबी लेखन सफल होता है लेकिन ब्रोकर कॉल विफल हो जाती है, तो व्यावसायिक निर्णय जारी रहता है लेकिन घटना कभी प्रकाशित नहीं होती है - डाउनस्ट्रीम सेवाओं को इस निर्णय के बारे में कभी भी सूचित नहीं किया जाएगा।```text
1. DB: Order.Status = Captured  ✓ (commit edildi)
2. Broker.Publish(OrderCaptured)  ✗ (network hatası, process crash)

Sonuç: Order tablosunda Captured var, ama hiçbir servise event gitmedi
```इसका विपरीत भी संभव है: ईवेंट प्रकाशित हो गया है लेकिन डीबी लेनदेन रोलबैक है; इस मामले में, डाउनस्ट्रीम सेवाएँ उस घटना पर प्रतिक्रिया करती हैं जो कभी घटित ही नहीं हुई।

## आउटबॉक्स: लिखने और प्रसारित करने को एक ही लेनदेन पर ले जाएं

आउटबॉक्स पैटर्न इवेंट को सीधे ब्रोकर को प्रसारित करने के बजाय, व्यवसाय निर्णय के समान डेटाबेस लेनदेन के भीतर एक आउटबॉक्स तालिका में लिखता है। यह रेखा अब व्यावसायिक निर्णयों द्वारा परमाणु रूप से कायम है - या तो दोनों प्रतिबद्ध हैं या कोई नहीं।```text
Tek transaction:
  UPDATE orders SET status = 'Captured' WHERE id = 42;
  INSERT INTO outbox (event_type, payload, dispatched_at) VALUES ('OrderCaptured', ..., NULL);
COMMIT
```एक अलग प्रकाशक प्रक्रिया समय-समय पर आउटबॉक्स में `dispatched_at IS NULL` पंक्तियों को स्कैन करती है, उन्हें ब्रोकर को प्रकाशित करती है, और सफल होने पर, `dispatched_at` फ़ील्ड को पॉप्युलेट करती है। यदि यह प्रकाशक एक से अधिक उदाहरणों के साथ काम करता है, तो एक ही समय में दो उदाहरणों को एक ही पंक्ति प्राप्त करने से रोकने के लिए एक पट्टा (अल्पकालिक लॉक) तंत्र का उपयोग किया जाता है।```text
Publisher A: satır #7'yi lease'ler (30 sn) → broker'a yayınlar → dispatched_at = now()
Publisher B: satır #7 lease'li, atlar; başka satır arar
```यह चरण सुनिश्चित करता है कि ईवेंट कम से कम एक बार प्रसारित हो - लेकिन प्रकाशक क्रैश होने पर यह दो बार प्रसारित हो सकता है। इसलिए उपभोक्ता पक्ष की रक्षा की आवश्यकता है।

## इनबॉक्स: उपभोक्ता पक्ष पर कटौती

चूँकि आउटबॉक्स कम से कम एक बार प्रसारण की गारंटी देता है, उपभोक्ता एक ही ईवेंट को एक से अधिक बार प्राप्त कर सकता है। ईवेंट को सीधे संसाधित करने के बजाय, इनबॉक्स पैटर्न पहले इसे एक अद्वितीय ईवेंट आईडी के साथ इनबॉक्स तालिका में लिखता है; यदि यह लेखन पहले से मौजूद है (अद्वितीय बाधा उल्लंघन), तो घटना दोबारा संसाधित नहीं होती है।```text
Tüketici event alır: event_id=evt_001
  INSERT INTO inbox (event_id, status) VALUES ('evt_001', 'received')
  → başarılı: iş bir job'a kuyruklanır
  → unique constraint hatası: zaten görülmüş, sessizce atlanır
```## आउटबॉक्स + इनबॉक्स = प्रभावी ढंग से-एक बार

आउटबॉक्स यह सुनिश्चित करता है कि प्रसारण नष्ट न हो (कम से कम एक बार)। इनबॉक्स यह सुनिश्चित करता है कि एक ही प्रसारण को उपभोक्ता पक्ष (निष्क्रिय उपभोक्ता) पर दो बार संसाधित नहीं किया जाता है। जब ये दोनों मिल जाते हैं, तो सिस्टम व्यावहारिक रूप से "बिल्कुल एक बार" व्यवहार करता है - इसे प्रभावी-एक बार कहा जाता है; बिल्कुल सही-एक बार वितरित प्रणालियों में गारंटी लगभग असंभव है, लेकिन यह संयोजन व्यवहार में इसका पर्याप्त अनुमान है।```text
Outbox (gönderen)  → at-least-once yayın
Inbox (alan)        → idempotent tüketim
─────────────────────────────────────────
Toplam davranış     → effectively-once

इस एपिसोड में सबसे भ्रमित करने वाला मैचअप```text

❌ DB'ye yazıp hemen ardından broker'a publish etmek güvenlidir ✓ Bu iki adım atomik değildir; aralarında dual-write hole vardır

❌ Outbox tek başına tekrar teslimatı önler ✓ Outbox at-least-once garanti eder; tekrar teslimata karşı tüketici tarafında inbox gerekir

❌ Lease, kalıcı bir kilittir ✓ Lease geçici ve süreli bir kilittir; publisher crash olursa süre dolunca serbest kalır

❌ Effectively-once, exactly-once ile aynı şeydir ✓ Exactly-once dağıtık sistemlerde pratik değildir; effectively-once, at-least-once + idempotency'nin sonucudur

## आपके आउटबॉक्स/इनबॉक्स सेटअप की चेकलिस्ट

1. क्या आप अपना व्यावसायिक निर्णय डीबी को लिख रहे हैं और एक ही लेनदेन में या दो अलग-अलग चरणों में की गई घटना को प्रकाशित कर रहे हैं?
2. यदि आपका आउटबॉक्स प्रकाशक एक से अधिक उदाहरणों के साथ काम करता है, तो क्या आपके पास एक पट्टा तंत्र है जो दो उदाहरणों को एक ही पंक्ति प्राप्त करने से रोकता है?
3. यदि प्रकाशक क्रैश हो जाता है, तो क्या लीज समाप्त होने के बाद लाइन को फिर से आजमाया जा सकता है, या क्या यह हमेशा के लिए "लीज" बनी रहेगी?
4. उपभोक्ता पक्ष पर, क्या आपकी इनबॉक्स तालिका में ईवेंट आईडी के लिए कोई अद्वितीय बाधा है?
5. क्या कोई मीट्रिक/अलार्म है जो आउटबॉक्स (प्रकाशन विलंब संकेतक) में `dispatched_at IS NULL` के साथ पंक्तियों की संख्या को ट्रैक करता है?

यदि आप इन पाँच प्रश्नों में से दो का उत्तर विश्वास के साथ नहीं दे सकते हैं, तो संभवतः आपका सिस्टम अभी भी दोहरे-लेखन छेद के प्रति संवेदनशील है।

## इस अनुभाग से याद रखने योग्य बातें

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

> आउटबॉक्स के बिना प्रकाशित कोई ईवेंट फेंकते ही गायब हो सकता है। इनबॉक्स के बिना प्राप्त एक ईवेंट को दो बार संसाधित किया जा सकता है, जिससे इसे खोना दोगुना महंगा हो जाता है।