आउटबॉक्स- पैटर्न

आउटबॉक्स एक वास्तुशिल्प पैटर्न है जिसमें एक डोमेन सेवा एक व्यवसाय परिवर्तन और एक स्थानीय लेनदेन में संबंधित घटना को अपने भंडार में लिखती है। बाहरी बस/कतार में घटना को प्रकाशित करना एक अलग सुरक्षित प्रक्रिया (प्रकाशक) द्वारा अतुल्यकालिक रूप से किया जाता है जो 'आउटबॉक्स' तालिका पढ़ ता है और रिकॉर्ड को रिले करता है। यह दृष्टिकोण दौड़ को "पहले डेटाबेस, फिर बस में" समाप्त करता है और विफलताओं के मामले में भी विश्वसनीय वितरण प्रदान करता है।

1) कब लागू करें

• संदर्भों के बीच घटनाओं के साथ Microservices और मॉड्यूलर मोनोलिथ।
• यह सुनिश्चित करने के लिए आवश्यक है कि "राज्य तय हो - घटना खो नहीं सकती है।"
• हमें पहचान और नियंत्रित पुन: वितरण की आवश्यकता है।

• कई संसाधनों पर कठिन वैश्विक लेनदेन महत्वपूर्ण हैं (स्पष्ट अनुबंधों के साथ टीसीसी/सागा से बेहतर)।
• सत्य का कोई समर्पित स्रोत नहीं है (राज्य संग्रहीत नहीं है जहां घटना उत्पन्न होती है)।

2) उद्देश्य और गुण

परमाणु लेखन: डोमेन रिकॉर्ड + आउटबॉक्स - एक लेनदेन में।

कम से कम एक बार प्रकाशन: हम पुनरावृत्ति की अनुमति देते हैं, नुकसान को बाहर करते हैं।

उपभोक्ता की पहचान: ग्राहक पक्ष के खिलाफ सुरक्षा।

प्रभावी बिल्कुल एक बार: आउटबॉक्स + आइडेम्पोटेंट उपभोक्ता + डेडअप के संयोजन से हासिल किया।

स्पष्ट टेलीमेट्री - व्यावसायिक लेनदेन और घटनाओं को सहसंबद्ध करें।

3) डेटा स्कीमा (उदाहरण)

sql
-- Domain table (example: orders)
CREATE TABLE orders (
id       UUID PRIMARY KEY,
tenant_id    TEXT NOT NULL,
status     TEXT NOT NULL,
total_amount  NUMERIC(12,2) NOT NULL,
updated_at   TIMESTAMP NOT NULL DEFAULT now()
);

-- Outbox
CREATE TABLE outbox (
id       UUID PRIMARY KEY,        -- event_id aggregate_type TEXT NOT NULL,          -- 'order'
aggregate_id  UUID NOT NULL,          -- order_id tenant_id    TEXT NOT NULL,
type      TEXT NOT NULL,          -- 'OrderCreated'
payload JSONB NOT NULL, -- serialized headers event JSONB NOT NULL DEFAULT '{}':: jsonb,
occurred_at TIMESTAMP NOT NULL, -- time in domain transaction available_at TIMESTAMP NOT NULL, -- earliest publish time (backoff)
published_at TIMESTAMP, - is filled by the attempts INT NOT NULL DEFAULT 0,
error      TEXT
);

CREATE INDEX ON outbox (available_at) WHERE published_at IS NULL;
CREATE INDEX ON outbox (tenant_id, available_at) WHERE published_at IS NULL;

4) अनुप्रयोग परत

pseudo begin tx domainChange () # INSERT/UPDATE in domain table insert into outbox (event) # event with aggregate/tenant commit tx keys

यदि प्रतिबद्धता सफल है, तो आउटबॉक्स में घटना मौजूद होने की गारंटी है। यदि आवेदन प्रतिबद्धता के बाद गिरता है, तो प्रकाशक पकड़ लेगा।

5) प्रकाशक (पाठक → प्रकाशक)

• समय-समय पर अप्रकाशित घटनाओं ('प्रकाशित _ at IS NULL' और 'उपलब्ध _ at <= अब ()'), बैचों को पढ़ें।
• बस/कतार में प्रकाशित करने की कोशिश करें; यदि सफल हो, तो 'प्रकाशित _ at' चिह्नित करें।
• त्रुटि - वृद्धि के मामले में 'प्रयास', भविष्य के लिए 'उपलब्ध _ at' रखें (घातीय बैकऑफ), 'त्रुटि' लिखें।
• किरायेदारों/कुंजियों (निष्पक्षता) की सीमाओं का सम्मान करें, उत्पाद को अवरुद्ध न करें।

pseudo loop:
events = select from outbox where published_at is null and available_at <= now()
order by occurred_at limit BATCH_SIZE for update skip locked

for e in events:
try:
broker. publish(topicFor(e), serialize(e. payload), headers(e))
markPublished(e. id, now())
except Retryable:
backoff = computeBackoff(e. attempts)
reschedule(e. id, now()+backoff, attempts+1, last_error)
except NonRetryable:
moveToDLQ (e) or markError (e) # by sleep (POLL_INTERVAL) policy

6) पहचान और कमी

sql
CREATE TABLE inbox (
consumer_name  TEXT,
event_id    UUID,
processed_at  TIMESTAMP NOT NULL,
PRIMARY KEY (consumer_name, event_id)
);

एल्गोरिथ्म: एक घटना प्राप्त करते समय, पहले 'इनबॉक्स' में 'INSERT' की कोशिश करें; यदि कोई महत्वपूर्ण संघर्ष है, तो घटना को पहले ही संभाला जा चुका है - नो-ऑप। अगला व्यापार तर्क है।

प्रकाशक की ओर: हेडर में 'आइडेम्पोटेंसी-की' (उदाहरण के लिए, 'इवेंट _ आईडी') ताकि बस/ब्रोकर/प्रॉक्सी डुप्लिकेट को फ़िल्टर कर सकें।

7) आदेश और कारण

'agregate _ id' द्वारा स्थानीय आदेश 'occured _ at' और "कुंजी द्वारा" प्रकाशित करके प्रदान किया गया है।

विभाजन के साथ लॉग-बसों के लिए - 'एग्रीगेट _ आईडी '/' टेनेंट _ आईडी' कुंजी के साथ विभाजन ताकि एक ही विभाजन की घटनाएं एक ही विभाजन में हों।

यदि आदेश महत्वपूर्ण है, तो क्रॉस-फ्लो एकल-कुंजी प्रकाशक दौड़ से बचें।

8) सीडीसी (डेटा कैप्चर बदलें)

एक सक्रिय प्रकाशक के बजाय, आप सीडीसी का उपयोग कर सकते हैं: इंजन डेटाबेस लेनदेन लॉग पढ़ ता है और बस में 'आउटबॉक्स' लाइनों का अनुवाद करता है। डेटाबेस पर सटीक अनुक्रम, कोई मतदान नहीं। नुकसान - ऑपरेशन की जटिलता और डीबीएमएस की बारीकियों के लिए एक टाई। दोनों दृष्टिकोण मान्य हैं; दक्षता और एसएलओ द्वारा चुनें।

9) त्रुटियां, डीएलक्यू और रेड्राइव

पुनः प्राप्य (नेटवर्क, सीमा) - 'अटेम्प्ट्स' को बढ़ाएं, 'available _ at' (घातीय बैकऑफ + jitter) को स्थगित करें।

गैर-पुनर्प्राप्य (अमान्य योजना/अनुबंध) - समृद्ध मेटाडेटा के साथ डीएलक्यू/मृत-पत्र विषय पर स्थानांतरित।

सुरक्षित Redrive: बैच, दर-सीमा, योजना का सत्यापन, उत्पादन यातायात के नीचे प्राथमिकता।

10) बहु-किरायेदारी और सीमा

आवश्यक टैग: 'किरायेदार _ id', 'योजना', 'क्षेत्र' - इन 'आउटबॉक्स। हेडर '।

प्रति-किरायेदार निष्पक्षता: प्रकाशक प्रकाशनों की "खिड़कियां" और किरायेदारों के प्रयासों की सीमा वितरित करता है।

रेजीडेंसी: डोमेन डेटा के समान क्षेत्र में आउटबॉक्स स्टोर करें; अंतःक्षेत्रीय प्रकाशन - समुच्चय/सारांश केवल।

11) सुरक्षा और अनुपालन

किरायेदार/क्षेत्र नीति पर पेलोड/हेडर में पीआईआई संस्करण।

यदि बस विदेशी है तो नीतभार का हस्ताक्षर/गोपन।

सभी राज्य संक्रमणों का लेखा परीक्षण करें: बनाया, प्रकाशित, त्रुटि, पुनर्वि

12) अवलोकन क्षमता

• प्रकाशन अंतराल ('अब - p50/p95/p99)।
• सफलता दर, त्रुटि दर, कारण वितरण।
• आउटबॉक्स आकार (अप्रकाशित की संख्या), पुनरावृत्ति/सेक
• प्रति-किरायेदार रेखांकन थ्रूपुट और अंतराल।

• सहसंबंध 'घटना _ id '/' कुल _ id '/' saga _ id'; "db-tx", "प्रकाशन", "retry" फैलाता है।
• एनोटेशन: 'प्रयास', 'backoff _ ms', 'dlq = true'।

• सफलता के लिए लघु रिकॉर्ड; प्रति त्रुटि/redrave पूर्ण विवरण।

13) परीक्षण और अराजकता

परमाणु परीक्षण: प्रकाशन से पहले एक डोमेन लेनदेन करने के बाद कृत्रिम रूप से "गिर" - घटना को बाद में जारी किया जाना चाहिए।

डुप्लिकेट परीक्षण: हम एक ही घटना को कई बार प्रकाशित करते हैं - उपभोक्ता बिल्कुल एक प्रभाव (इनबॉक्स) करता है।

आदेश परीक्षण: एक समुच्चय - अनुक्रम/पहचान जांच द्वारा घटनाओं का समूह।

अराजकता: ब्रोकर विफलता, डेटाबेस विलंबता में वृद्धि, विभाजन-मस्तिष्क प्रकाशक, घड़ी-तिरछा।

14) कॉन्फ़िगरेशन टेम्पलेट (उदाहरण)

yaml outbox:
poll_interval_ms: 200 batch_size: 200 order_by: occurred_at backoff:
strategy: exponential_full_jitter initial_ms: 250 max_ms: 10_000 max_attempts: 20 fairness:
per_tenant_parallelism: 4 per_key_serial: true

publisher:
rate_limit_per_sec: 500 headers:
idempotency_key: event_id schema_version: v3 dlq:
enabled: true topic: myapp. events. dlq include_metadata:
- error
- attempts
- source_table
- tenant_id
- aggregate_id

15) सागा और रिट्रीट के साथ एकीकरण

आउटबॉक्स - गाथा चरणों के लिए "सुरक्षा परिवहन": स्थानीय लेनदेन प्रभाव और कमांड/घटना लिखता है; प्रकाशन - विश्वसनीय और खुदाई।

दोहराने और बैकऑफ नीतियों को 'रीट्री-आफ्टर' और सर्किट ब्रेकर के अनुरूप होना चाहिए; "रेट्रे तूफान" से बचें।

16) विशिष्ट त्रुटियाँ

वे डोमेन राज्य प्रतिबद्धता के बाद एक घटना लिखते हैं - एक गिरावट के दौरान हानि संभव है।

'outbox' में कोई सूचकांक/संग्रह नहीं - प्रकाशन विलंबता वृद्धि।

'SKIP LOCKED' के बिना या बिना शार्डिंग - प्रतिस्पर्धा और अवरोधन के प्रकाशक।

उपभोक्ताओं में पहचान की कमी - डुप्लिकेट और दुष्प्रभाव।

DLQ/लॉग में मास्किंग के बिना PII मिश्रण।

निष्पक्षता के बिना एक एकल वैश्विक प्रकाशन कतार - एक "शोर" किरायेदार सभी को धीमा कर देता है।

अंतराल निगरानी की कमी - अव्यक्त गिरावट।

17) त्वरित रणनीति पसंद

शुरुआती स्तर: डेटाबेस से मतदान, 100-500 बैच, फुल-जिटर बैकऑफ, उपभोक्ताओं के लिए इनबॉक्स।

उच्च भार: लेनदेन लॉग से सीडीसी, 'किरायेदार _ आईडी/एग्रीगेट _ आईडी' द्वारा शार्टिंग, किरायेदार द्वारा WFQ।

कुल द्वारा सख्त आदेश: प्रति कुंजी (म्यूटेक्स) धारावाहिक प्रकाशन, एक कुंजी के साथ विषय का विभाजन।

अनुपालन/पीआईआई: पेलोड एन्क्रिप्शन, डीएलक्यू संस्करण, क्षेत्रीय आउटबॉक्स।

18) प्री-सेल चेकलिस्ट

• डोमेन बदलता है और 'आउट बॉक्स' लिखता है एक ही लेनदेन में होता है।
• प्रकाशक बैचों को संभालता है, 'SKIP LOCKED' का उपयोग करता है, जिटर और लिमिट के साथ बैकऑफ करता है।
• उपभोक्ता अज्ञात हैं (तालिका 'इनबॉक्स '/डेडअप लॉग)।
• DLQ और सुरक्षित रिलीज़ कॉन्फ़िगर किए गए हैं।
• p95/p99 थ्रेसहोल्ड पर लैग/त्रुटि और अलर्ट मेट्रिक्स।
• कुंजी क्रम की गारंटी है (बैच/धारावाहिक)।
• आर्काइव/रिटेंशन 'आउटबॉक्स' और स्पष्ट प्रकाशित रिकॉर्ड।
• पीआईआई नीतियां और राज्य संक्रमण ऑडिटिंग।
• प्रतिबद्ध और प्रकाशित, डुप्लिकेट और क्रम के बीच परीक्षण छोड़ दें।
• घटना अनुबंध प्रलेखन (स्कीमा/संस्करण/संगतता)।

निष्कर्ष

आउटबॉक्स पैटर्न "डीबी" बस के "नाजुक" बंडल को एक विश्वसनीय पाइपलाइन में बदल देता है: परमाणु राज्य निर्धारण, गारंटी (यद्यपि "कम से कम एक बार") प्रकाशन, मूर्त ग्राहक और नियंत्रित redrave। उचित टेलीमेट्री, सीमा और स्कीमा अनुशासन के साथ, यह व्यावहारिक रूप से एक बार व्यवहार देता है, वितरित लेनदेन की जटिलता को कम करता है और क्रैश और पीक लोड के लिए सिस्टम की लचीलापन को बढ़ाता है।