भुगतान समाधान कार्यकर्ता निर्माण (Building A Payment Reconciliation Worker)

पिछले भाग में, हमने देखा कि लीज तंत्र के साथ किसी व्यवसाय का सुरक्षित स्वामित्व कैसे किया जा सकता है। लेकिन यहां तक ​​कि सबसे मजबूत पट्टा भी एक तथ्य को नहीं बदल सकता है: कभी-कभी कार्यकर्ता को पीएसपी से एक निश्चित प्रतिक्रिया प्राप्त करने से पहले समय समाप्त हो जाता है, प्रक्रिया क्रैश हो जाती है, या पट्टा समाप्त हो जाता है और नौकरी को 'समाप्त' के रूप में चिह्नित किया जाता है - बस जब पीएसपी की ओर से भुगतान वास्तव में सफल रहा हो।

यह सुलह कार्यकर्ता का उद्देश्य है: एक सफाई कर्मचारी जो समय-समय पर स्थानीय प्रणाली और पीएसपी के स्वयं के रिकॉर्ड के बीच बहाव को स्कैन और ठीक करता है।```text Local kayıt: Payment #123 → Expired PSP kaydı: Payment #123 → Succeeded │ ▼ Mutabakat worker sürüklenmeyi tespit eder │ ▼ Local kayıt → Captured olarak düzeltilir

## पहले उल्लेख पर अवधारणाएँ```text
📦 Reconciliation (Mutabakat)
İki bağımsız kaynağın (local sistem ve PSP) kayıtlarını karşılaştırıp farkı düzeltme süreci.

📦 Drift (Sürüklenme)
Local durumun PSP'nin gerçek kaydından farklılaşması; genellikle bir hata veya zaman aşımı sonucu.

📦 Sweeper
Belirli bir kritere uyan (örn. 'aged' veya 'expired') kayıtları periyodik olarak tarayan arka plan işi.

📦 FinalizePending
Ödemenin PSP tarafında sonuçlanmış olabileceği ama local sistemde henüz kesin bir duruma geçmediği ara statü.
```सुलह कोई वास्तविक समय का समाधान नहीं है; यह एक सुरक्षा जाल है. मुख्य प्रवाह (वेबहुक, सिंक्रोनस रिस्पांस) अधिकांश समय सही ढंग से काम करता है; सर्वसम्मति से उस अल्पसंख्यक को हटा दिया जाता है जो 'अधिकांश समय' से बाहर रह जाता है।

## बहाव के वास्तविक स्रोत

बहाव शायद ही कभी यादृच्छिक होता है; आम तौर पर विशिष्ट, दोहराव वाले परिदृश्यों से आता है: कार्यकर्ता पीएसपी को अनुरोध भेजता है, प्रतिक्रिया आने से पहले प्रक्रिया क्रैश हो जाती है; नेटवर्क त्रुटि के कारण प्रतिक्रिया कभी नहीं आती है, लेकिन लेनदेन पीएसपी पक्ष पर पूरा हो जाता है; या पट्टे की अवधि पीएसपी के प्रतिक्रिया समय से कम निर्धारित की गई है और कार्य को समय से पहले 'समाप्त' के रूप में चिह्नित किया गया है।```text
Senaryo 1: Worker çöktü
  Request gönderildi → PSP işledi → Worker cevabı hiç okuyamadı

Senaryo 2: Ağ hatası
  Request gönderildi → PSP işledi → yanıt ağda kayboldu

Senaryo 3: Lease erken doldu
  Request gönderildi → PSP yavaş yanıt verdi → lease expired → job stuck watcher tarafından sıfırlandı → ama PSP zaten başarılı olmuştu
```तीनों परिदृश्यों में जो समानता है वह यह है कि **स्थानीय रजिस्ट्री** अनिश्चित या गलत स्थिति में रहती है, जबकि **पीएसपी की अपनी रजिस्ट्री** पहले से ही सही परिणाम जानती है।

## स्वीपर की क्वेरी: कौन सा रिकॉर्ड स्कैन करना है

समाधान कार्यकर्ता लगातार प्रत्येक रिकॉर्ड की तुलना पीएसपी से नहीं करता है - यह महंगा और अनावश्यक है। यह केवल 'संदिग्ध' रिकॉर्ड को लक्षित करता है: ऐसे रिकॉर्ड जो एक निश्चित आयु (पुराना) पार कर चुके हैं और अभी भी मध्यवर्ती स्थिति (`FinalizePending`, `Expired`, `Processing` लंबे समय तक) में बने हुए हैं।```sql
SELECT id, provider_ref FROM payments
WHERE status IN ('FinalizePending', 'Expired')
  AND updated_at < now() - interval '10 minutes';
```'10 मिनट' की सीमा मनमानी नहीं है; यह एक एसएलए से आता है कि सामान्य प्रवाह को परिणाम देने में कितना समय लगना चाहिए। इस सीमा से नीचे के रिकॉर्ड अभी तक 'संदिग्ध' नहीं हैं, वे धीमे हो सकते हैं।

## पीएसपी पर सवाल उठाना और निर्णय लेना

प्रत्येक उम्मीदवार रिकॉर्ड के लिए, कार्यकर्ता पीएसपी की स्थिति क्वेरी एपीआई (यदि उपलब्ध हो) या अपने स्वयं के संग्रहीत वेबहुक इतिहास की जांच करता है। तीन परिणाम संभव हैं:```text
PSP: Succeeded  → local kaydı Captured'a taşı, semantik event yayınla
PSP: Failed     → local kaydı Failed'a taşı
PSP: Not Found / Unknown → local kaydı gerçekten sonuçsuz say, telafi akışına yönlendir
```यहां महत्वपूर्ण बिंदु यह है कि यह परिवर्तन भी निष्प्रभावी होना चाहिए: भले ही सुलह कार्यकर्ता एक ही रिकॉर्ड को दो बार संसाधित करता है, तब भी परिणाम नहीं बदलना चाहिए (उदाहरण के लिए, यदि रिकॉर्ड पहले से ही `Captured` है, तो उसे उसी घटना को दोबारा जारी नहीं करना चाहिए)।

##चेतावनी: सफाईकर्मी को चुपचाप नहीं भागना चाहिए

सर्वसम्मति कार्यकर्ता द्वारा खोजे गए प्रत्येक बहाव से एक अवलोकन संकेत उत्पन्न होना चाहिए। यदि बहाव की संख्या अचानक बढ़ जाती है, तो यह आमतौर पर मुख्य प्रवाह (वेबहुक प्रोसेसिंग, लीज अवधि, नेटवर्क) में एक समस्या का संकेत देता है - सामंजस्य को इस समस्या को दृश्यमान बनाना चाहिए, छिपाना नहीं चाहिए।

| मीट्रिक | यह क्या कहता है |
| --- | --- |
| स्कैन किए गए उम्मीदवार पंजीकरण की संख्या | मुख्य धारा कितनी 'स्वच्छ' चलती है |
| सही बहाव की संख्या | वास्तविक डेटा विसंगति मात्रा |
| रिकॉर्ड की संख्या अभी भी अनसुलझी है | मैन्युअल समीक्षा की आवश्यकता वाली कतार |

## अक्सर भ्रमित होने वाले भेद```text
❌ Mutabakat gerçek zamanlı bir düzeltmedir
✓ Mutabakat periyodik bir güvenlik ağıdır, ana akışın yerini almaz

❌ Sürüklenme sayısı sıfır olmalı, aksi halde sistem bozuk
✓ Düşük ve stabil bir sürüklenme oranı normaldir; artan oran bir sinyaldir

❌ Her kayıt PSP ile karşılaştırılmalı
✓ Sadece 'aged' ve ara statüdeki kayıtlar hedeflenmeli
```## मुख्य प्रवाह के साथ सर्वसम्मति की भूमिका

| आकार | मुख्य धारा (वेबहुक/सिंक्रोनस) | सुलह कार्यकर्ता |
| --- | --- | --- |
| गति | सेकंड | मिनट-घंटे |
| दायरा | हर भुगतान | केवल संदिग्ध/पुराने रिकॉर्ड |
| उद्देश्य | सामान्य तरीका | सुरक्षा जाल |

## सुलह कार्यकर्ता स्थापित करते समय चेकलिस्ट

1. क्या स्वीपर क्वेरी व्यवसाय एसएलए के आधार पर 'वृद्ध' सीमा निर्धारित करती है या यह एक यादृच्छिक संख्या है?
2. क्या पीएसपी से पूछताछ करना इसकी दर सीमा और पुनः प्रयास नीति का अनुपालन करता है?
3. क्या बहाव सुधार निष्प्रभावी है - क्या एक ही रिकॉर्ड को दो बार संसाधित करने पर परिणाम नहीं बदलता है?
4. क्या ठीक न किये जा सकने वाले रिकॉर्ड दृश्यमान कतार में आते हैं (जो PSP पर भी नहीं मिल सकते)?
5. क्या बहाव की संख्या को एक मीट्रिक के रूप में मॉनिटर किया जाता है और अचानक वृद्धि के लिए अलार्म उत्पन्न किया जाता है?

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

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

> एक सर्वसम्मति कार्यकर्ता दिखाता है कि सिस्टम कितना ईमानदार है, न कि यह कितना सही है।

अगले भाग में हम इस बहाव के सबसे कष्टप्रद रूप पर विचार करते हैं: ग्राहक से पीएसपी की ओर से शुल्क लिया गया है लेकिन सिस्टम में कोई ऑर्डर नहीं है - और हम इसे सुरक्षित रूप से कैसे ठीक कर सकते हैं?