Transactional Outbox पैटर्न: माइक्रोसर्विसेज में विश्वसनीय इवेंट पब्लिशिंग

आधुनिक इवेंट-संचालित माइक्रोसर्विसेज आर्किटेक्चर (Event-Driven Architecture) में, सेवाएं राज्यों के परिवर्तनों को सूचित करने के लिए नियमित रूप से इवेंट्स (जैसे OrderCreated या PaymentProcessed) जारी करती हैं।

लेकिन एक चुनौती यह है: आप यह कैसे सुनिश्चित कर सकते हैं कि डेटाबेस अपडेट और इवेंट पब्लिशिंग दोनों एक साथ सफल हों या दोनों विफल हों?

यदि कोई माइक्रोसर्विस अपने स्थानीय डेटाबेस (जैसे PostgreSQL या MySQL) को अपडेट करती है और फिर नेटवर्क के माध्यम से मैसेज ब्रोकर (जैसे Apache Kafka या RabbitMQ) पर इवेंट भेजने का प्रयास करती है, तो नेटवर्क विफलता डेटा विसंगति पैदा कर सकती है।

इस समस्या के समाधान के लिए Transactional Outbox पैटर्न का उपयोग किया जाता है।

मुख्य समस्या: डुअल-राइट समस्या (Dual-Write Problem)

जब कोई सेवा लगातार दो अलग-अलग राइट कार्य करने का प्रयास करती है:

1. व्यावसायिक डेटा को स्थानीय डेटाबेस में सहेजना।
2. मैसेज ब्रोकर को इवेंट पब्लिश करना।

यदि डेटाबेस सेव सफल हो जाता है लेकिन नेटवर्क एरर के कारण Kafka पर मैसेज विफल हो जाता है, तो डेटाबेस में डेटा रहेगा लेकिन डाउनस्ट्रीम सेवाओं को सूचित नहीं किया जाएगा। परिणाम: डेटा विसंगति।

Transactional Outbox पैटर्न क्या है?

यह पैटर्न रिलेशनल डेटाबेस के स्थानीय ACID ट्रांजेक्शन का उपयोग करता है।

इवेंट को सीधे नेटवर्क पर भेजने के बजाय, सेवा उसी स्थानीय ट्रांजेक्शन के भीतर Outbox Table नामक एक समर्पित तालिका में इवेंट पेलोड लिखती है जिसमें व्यावसायिक डेटा सहेजा जाता है।

ACID गारंटी के कारण: या तो दोनों राइट एक साथ कमिट होते हैं या दोनों रद्द हो जाते हैं।

बाद में, एक स्वतंत्र बैकग्राउंड प्रोसेस (Message Relay) Outbox तालिका को पढ़ता है और मैसेज ब्रोकर को संदेश भेजता है।

मैसेज रिले रणनीतियाँ: Polling Publisher बनाम CDC (Debezium)

1. पोलिंग पब्लिशर (Polling Publisher)

एक बैकग्राउंड जॉब समय-समय पर अप्रसंस्कृत रिकॉर्ड्स की जांच करता है, Kafka पर पब्लिश करता है और स्थिति अपडेट करता है।

• लाभ: लागू करना आसान, अतिरिक्त इंफ्रास्ट्रक्चर की आवश्यकता नहीं।
• हानि: पोलिंग अंतराल के कारण देरी और डेटाबेस पर अतिरिक्त लोड।

2. चेंज डेटा कैप्चर (CDC with Debezium)

Debezium सीधे डेटाबेस ट्रांजेक्शन लॉग्स (PostgreSQL WAL) को पढ़ता है और परिवर्तनों को तुरंत Kafka में स्ट्रीम करता है।

• लाभ: लगभग शून्य देरी और एप्लिकेशन पर शून्य लोड।
• हानि: Kafka Connect और Debezium इंफ्रास्ट्रक्चर सेटअप की आवश्यकता।

निष्कर्ष

Transactional Outbox पैटर्न वितरित प्रणालियों में अंतिम संगति (Eventual Consistency) और डेटा विश्वसनीयता सुनिश्चित करने के लिए एक अत्यंत महत्वपूर्ण आर्किटेक्चरल पैटर्न है।