भुगतान प्रणालियाँ वितरित प्रणालियाँ क्यों हैं? (Why Payment Systems Are Distributed Systems)

भुगतान कोई बटन नहीं, समन्वय है

जब आप किसी ई-कॉमर्स प्लेटफॉर्म पर "भुगतान ले लो" कहते हैं, तो आप वास्तव में चाहते हैं कि पांच अलग-अलग प्रणालियाँ एक ही तथ्य पर सहमत हों: क्या गाड़ी जमी हुई है, क्या स्टॉक है, क्या प्रदाता गेटवे को पैसा प्राप्त हुआ है, क्या ऑर्डर की पुष्टि हो गई है, क्या वित्तीय रिकॉर्ड सही है। ये सभी एक ही प्रक्रिया, एक ही लेन-देन में नहीं रहते।```text Sepet Servisi Stok Servisi Checkout Orchestrator Provider Gateway Finans/Ledger | | | | | +---------------+------------------+--------------------+----------------+ aynı sipariş, beş farklı gerçek

## पहले उल्लेख पर अवधारणाएँ```text
📦 Checkout Orchestrator
Sipariş akışının adımlarını (sepet, ödeme, stok, onay) koordine eden servis; para veya stok tutmaz, kararları sıralar.

📦 Provider Gateway
Gerçek ödeme sağlayıcısını (PSP) uygulama iç modeline çeviren soyutlama katmanı.

📦 PSP (Payment Service Provider)
Kartı veznede tutan, parayı fiilen çeken dış sistem; sizin transaction sınırınızın dışındadır.

📦 Dağıtık Transaction
Birden fazla bağımsız sistemin, tek bir “hepsi ya da hiçbiri” garantisi altında değişmesi gereken işlem.

📦 Eventual Consistency
Sistemlerin şu an değil, kısa bir süre içinde aynı gerçeğe yakınsayacağını kabul eden tutarlılık modeli.
```इन पांच अवधारणाओं को अलग करने में असमर्थ, एक टीम पीएसपी को अपने स्वयं के डेटाबेस के रूप में कार्य करने के लिए मजबूर करती है। PSP कभी भी आपके लेन-देन में भाग नहीं लेता; वह बस अपनी ही टाइमलाइन में अपना सत्य संप्रेषित करता है।

## एकल अनुरोध के लिए पाँच हस्ताक्षरों की आवश्यकता होती है

जब कोई ग्राहक "पे" बटन दबाता है, तो पृष्ठभूमि में निम्नलिखित निर्णय लिए जाते हैं: क्या टोकरी की कीमत स्थिर है, क्या स्टॉक आरक्षित है, क्या भुगतान अनुरोध प्रदाता गेटवे को भेजा गया है, क्या पीएसपी पैसे निकालता है, क्या ऑर्डर लाइनों को अंतिम रूप दिया गया है, क्या वित्तीय रिकॉर्ड खोला गया है। इनमें से प्रत्येक एक अलग सेवा की ज़िम्मेदारी है और एक अलग डेटाबेस में रहता है।

यहीं से समस्या शुरू होती है: यदि आप इन छह चरणों को एक ही HTTP अनुरोध श्रृंखला के भीतर समकालिक रूप से कॉल करते हैं, तो सिस्टम एक बिंदु से दूसरे बिंदु तक निर्भरता की एक लंबी और नाजुक श्रृंखला बन जाता है।```text
Client → Checkout Orchestrator → Sepet Servisi → Stok Servisi → Provider Gateway → PSP
```## तुल्यकालिक श्रृंखला कहाँ टूटती है?

जब इस श्रृंखला में कोई भी चरण टाइमआउट जारी करता है, तो आपके पास दो प्रश्न बचे होते हैं: क्या अनुरोध दूसरे पक्ष तक पहुंच गया, और यदि हां, तो क्या इस पर कार्रवाई की गई? पीएसपी से वापसी के टाइमआउट का मतलब यह नहीं है कि "कोई पैसा नहीं निकाला गया"; इसका मतलब है "मुझे उत्तर नहीं मिला।" एक ही अनुरोध दोबारा सबमिट करने पर ग्राहक को कैशियर के पास दो बार जाना पड़ सकता है।```text
Checkout Orchestrator --(timeout)--> Provider Gateway --(???)--> PSP
                                                        para çekildi mi, çekilmedi mi?
```यह अनिश्चितता तुल्यकालिक श्रृंखला का एक स्वाभाविक परिणाम है: नेटवर्क, परिभाषा के अनुसार, अविश्वसनीय है; आप श्रृंखला को जितना लंबा बढ़ाएंगे, उतनी ही अधिक अनिश्चितता बढ़ती जाएगी।

## यहां "सभी या कुछ भी नहीं" क्यों काम नहीं करता है

क्लासिक वितरित लेनदेन समाधान (जैसे कि दो-चरण प्रतिबद्धता) सभी प्रतिभागियों से एक ही समन्वयक, एक ही लॉकिंग प्रोटोकॉल और एक ही नेटवर्क विश्वसनीयता की अपेक्षा करते हैं। पीएसपी इस दुनिया का हिस्सा नहीं है: यह खुद को अनलॉक नहीं करता है, यह आपके कमिट/रोलबैक कॉल को नहीं सुनता है, यह आपको अपनी टाइमलाइन (वेबहुक, विलंबित अधिसूचना) पर सूचित करता है।

इसलिए, "भुगतान + स्टॉक + ऑर्डर" तिकड़ी को एक ही लेन-देन में फिट करने का प्रयास एक अघुलनशील समस्या को ऐसा प्रतीत करा रहा है जैसे इसे हल कर दिया गया है। आप वास्तव में जो कर रहे हैं वह गलती छिपा रहा है; आपने इसे ख़त्म नहीं किया है.

## घटना-आधारित समाधान: दो अलग-अलग तथ्य, दो अलग-अलग समयसीमाएँ

कामकाजी मॉडल सिंक्रोनस श्रृंखला को छोटा करना और बाकी को घटनाओं को सौंपना है। आप प्रदाता गेटवे को एक अनुरोध भेजते हैं, पीएसपी की प्रतिक्रिया (सिंक्रोनस रूप से या वेबहुक के माध्यम से) को एक घटना के रूप में रिकॉर्ड करते हैं, और ऑर्डर/इन्वेंट्री/वित्त पक्ष पर प्रत्येक चरण इस घटना पर प्रतिक्रिया करते हुए अपने आप में एक निष्क्रिय उपभोक्ता है।```text
Provider Gateway → PaymentCaptured (event) → Outbox
                                              ↓
                         Stok Servisi   Finans Servisi   Checkout Orchestrator
                         (bağımsız, kendi hızında, kendi retry'ıyla tüketir)
```इस मॉडल में, "भुगतान सफल" और "ऑर्डर पूरा" अब एक ही समय में होने वाली एक घटना नहीं है, बल्कि दो अलग-अलग तथ्य हैं जो एक-दूसरे का अनुसरण करते हैं, उनके बीच मापने योग्य देरी होती है। जो प्रणालियाँ इस भेद को स्वीकार नहीं करती हैं वे राज्य मशीन त्रुटियों की ओर प्रगति करती हैं, जिसे हम इस श्रृंखला के दूसरे भाग में देखेंगे।

## इस एपिसोड में सबसे भ्रमित करने वाला मैचअप```text
❌ Ödeme akışı = tek bir servisin fonksiyonu
✓ Ödeme akışı = birden fazla bağımsız servisin katıldığı bir koordinasyon

❌ PSP = bizim veritabanımızdaki bir tablo gibi davranır
✓ PSP = kendi zaman çizelgesi olan, dışarıdan gözlemlenen bir sistem

❌ Timeout = işlem başarısız oldu
✓ Timeout = işlemin sonucu bilinmiyor; retry idempotent olmadan güvenli değildir

❌ Dağıtık transaction ile bu problem “çözülebilir”
✓ Dağıtık transaction, PSP gibi harici sınırlarda pratikte uygulanamaz
```ये चार विसंगतियाँ अधिकांश "भुगतान पर कभी-कभी दोगुना शुल्क क्यों लगाया जाता है" घटनाओं की जड़ हैं।

## आपके अपने सिस्टम की चेकलिस्ट

1. आपके भुगतान प्रवाह में कितनी अलग-अलग सेवाएँ कितने अलग-अलग डेटाबेस में लिखती हैं? यह नंबर लिखें.
2. क्या प्रदाता गेटवे पर कॉल का समय समाप्त होने पर आपका कोड स्वचालित रूप से पुनः प्रयास करता है? क्या इस पुनः प्रयास में निष्क्रियता कुंजी है?
3. क्या "भुगतान सफल" जानकारी और "ऑर्डर पूरा हुआ" जानकारी एक ही पंक्ति में या अलग-अलग तालिकाओं में रखी गई हैं?
4. यदि पीएसपी से वेबहुक देरी से आता है या बिल्कुल नहीं आता है, तो आपके सिस्टम को नोटिस करने में कितने घंटे लगते हैं?
5. आपकी सिंक्रोनस श्रृंखला में सबसे लंबा चरण कौन सा है और यदि वह चरण गिर जाता है तो शेष चरण क्या करते हैं?

यदि आपके पास इन पाँच प्रश्नों के स्पष्ट उत्तर नहीं हैं, तो संभवतः आपका भुगतान प्रवाह "एकल लेनदेन" के भ्रम के साथ डिज़ाइन किया गया है।

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

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

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