उत्पादन में CQRS (कमांड क्वेरी रिस्पॉन्सिबिलिटी सेग्रीगेशन): संगति, त्रुटियाँ और पुनर्प्राप्ति रणनीतियाँ (CQRS 3)

How these failures look to a user

If a banking balance is delayed by two seconds, a user may think money disappeared. If a like count is delayed by two seconds, most users may accept it. The same technical lag creates two different product risks.

Likewise, if the same OrderPlaced message arrives twice, inventory can be reduced twice. Production concepts should therefore be read not only as definitions, but through their effect on the user and the business.

उत्पादन में असली सवाल

सुखद मार्ग सरल है: आदेश स्वीकार किया गया, घटना जारी की गई, प्रक्षेपण अद्यतन किया गया। प्रोडक्शन में, संदेश दो बार आता है, उपभोक्ता पीछे रह जाता है, प्रक्षेपण टूट जाता है, या उपयोगकर्ता सूची में लिखे गए ऑर्डर को नहीं देख पाता है।```text Command accepted → event published → projection delayed → user refreshes "Siparişim kayboldu mu?"

## पहले उल्लेख पर अवधारणाएँ```text
📦 Consistency lag
Write başarılı olduktan sonra read modelin güncellenmesine kadar geçen süre.

📦 Retry
Geçici teknik hatada aynı işi kontrollü biçimde yeniden deneme.

📦 Dead-letter queue (DLQ)
Normal akışta işlenemeyen mesajların incelenmek üzere ayrıldığı kuyruk.

📦 Checkpoint
Projection'ın güvenle işlediği son event konumu.
```**अंतिम स्थिरता** का मतलब यह नहीं है कि डेटा गलत है; अलग-अलग मॉडल अलग-अलग क्षणों में एक ही सत्य पर पहुंचते हैं। यदि यह स्वीकार्य है, तो उत्पाद को उपयोगकर्ता को यह सही ढंग से समझाना चाहिए; यदि नहीं, तो उसे महत्वपूर्ण क्वेरी के लिए एक अलग स्थिरता रणनीति चुननी चाहिए।

## Every defence has a reason

- We keep a **checkpoint** **because** a replay needs to know where a projection can safely resume.
- We need **idempotency** **because** applying a duplicate event twice corrupts real business effects such as inventory or payment.
- We limit **retry** **because** repeating a malformed message cannot repair it; it can only amplify load and incorrect impact.
- We use a **DLQ** **because** a message unresolved by the normal flow needs visible ownership and investigation.
- The **partition key is the aggregate ID** **because** the causal order of one aggregate matters more than global event order.
- We **replay** **because** verified event history remains correct even when a projection is broken.

## संगति में देरी एक उत्पाद निर्णय है, तकनीकी नहीं

यदि कोई भुगतान प्राप्त होने के बाद दो सेकंड तक ऑर्डर सूची में दिखाई नहीं देता है, तो यह उपयोगकर्ता को डेटा हानि जैसा महसूस हो सकता है। पहले दृश्यमान अनुबंध का निर्धारण करें: लेनदेन के तुरंत बाद कौन सी स्क्रीन अपडेट की जानी चाहिए और कितनी जल्दी?```text
POST /orders → 202 Accepted + orderId + version
GET /orders/{id}?minVersion=42
  → projection 42'ye ulaştıysa güncel görünüm
  → henüz ulaşmadıysa "işleniyor" durumu
```आशावादी यूआई, मतदान या प्रतीक्षा-संस्करण का उपयोग किया जा सकता है। ये अंतराल को रीसेट नहीं करते हैं; **क्योंकि** असली काम उपयोगकर्ता को ईमानदारी से देरी का अर्थ बताना है। महत्वपूर्ण निर्णयों के लिए, कमांड पक्ष का परिणाम सत्य रहता है।

## डुप्लिकेट घटना और अनुक्रम भ्रष्टाचार

कम से कम एक बार डिलीवरी से एक ही संदेश की पुनरावृत्ति सामान्य हो जाती है। एक ही ऑर्डर ईवेंट को दूसरी बार संसाधित करने से इन्वेंट्री संख्या दोगुनी हो सकती है। उपभोक्ता को इवेंट आईडी और समग्र संस्करण की जांच करनी चाहिए।```text
if event.id already processed: ignore
if event.version <= projection.version: ignore
apply event
store checkpoint and event id
```यह नियंत्रण अनुक्रमित लुकअप के साथ O(1) औसत या O(लॉग एन) लागत वहन करता है। यदि ऑर्डर देने की गारंटी केवल एक विभाजन के भीतर है, तो विभाजन कुंजी समग्र आईडी होनी चाहिए; **क्योंकि** उसी क्रम का कारण क्रम वैश्विक क्रम से महत्वपूर्ण है।

## पुनः प्रयास करें, डीएलक्यू और ऑपरेटर निर्णय क्षण

हर गलती की दोबारा कोशिश नहीं करनी चाहिए. नेटवर्क टाइमआउट अस्थायी हो सकता है; अमान्य ईवेंट स्कीमा एक स्थायी त्रुटि है.

| त्रुटि प्रकार | प्रतिक्रिया | क्यों |
| --- | --- | --- |
| टाइमआउट / 503 | घातीय बैकऑफ़ के साथ पुनः प्रयास करें | लत छुड़ाई जा सकती है |
| दर सीमा | विलंबित पुनः प्रयास | बिना बोझ बढ़ाए उबरना |
| स्कीमा सत्यापन त्रुटि | डीएलक्यू + अलार्म | पुनः प्रयास करने से संदेश ठीक नहीं हो सकता |
| व्यापार नियम का उल्लंघन | सहेजें, समीक्षा करें, क्षतिपूर्ति करें | स्वचालित पुनः प्रयास से गलत प्रभाव बढ़ सकता है |

DLQ कोई डंप नहीं है. प्रत्येक संदेश में एक स्वामी, समीक्षा समय, पुनः चलाने की प्रक्रिया और अलार्म होना चाहिए।

## यदि प्रोजेक्शन दूषित हो जाए तो कैसे ठीक करें?

प्रोजेक्शन कोई कैश नहीं है, यह एक प्रतिलिपि प्रस्तुत करने योग्य व्यावसायिक दृश्य है।```text
1. Consumer'ı durdur veya yeni projection sürümü oluştur
2. Son güvenli checkpoint'i doğrula
3. Event stream'i kontrollü replay et
4. Sayım ve örnek veri doğrulaması yap
5. Trafiği yeni projection'a yönlendir
6. Lag ve hata oranını izle
```पुनः चलाने की लागत O(n) है, जो घटनाओं की संख्या के साथ रैखिक है। स्नैपशॉट या खंडित रीप्ले इसे कम कर सकता है; लेकिन स्नैपशॉट स्रोत वास्तविक नहीं है. **क्योंकि** पुनर्प्राप्ति के लिए जिस रिकॉर्ड पर भरोसा किया जाना चाहिए वह सत्यापित घटना इतिहास है।

## सागा की विफलता का मार्ग

ई-कॉमर्स में भुगतान विफल होने पर स्टॉक हमेशा के लिए आरक्षित नहीं रहना चाहिए। सागा कोई तकनीकी रोलबैक नहीं है, बल्कि एक मुआवज़ा है जो व्यावसायिक समझ में आता है।```text
Reserve inventory → Capture payment → Create shipment
                 payment fails → Release inventory
```मुआवज़ा भी निरर्थक होना चाहिए: यदि रिलीज़इन्वेंटरी दो बार चलती है तो इन्वेंट्री दोगुनी नहीं बढ़नी चाहिए। कोरियोग्राफी छोटे स्थानीय प्रवाह पर प्रकाश डालती है; ऑर्केस्ट्रेशन एक बहु-चरणीय प्रक्रिया में एक राज्य मशीन और निगरानी का एक एकल बिंदु प्रदान करता है।

## अवलोकनशीलता

उपभोक्ता अंतराल, पुनः प्रयास गणना, डीएलक्यू गहराई, चेकपॉइंट आयु, डुप्लिकेट दर और एंड-टू-एंड प्रोसेसिंग समय को मापें। ट्रेस आईडी को कमांड से इवेंट, उपभोक्ता और उपयोगकर्ता के पास लौटने वाली क्वेरी पर ले जाएं। अलार्म उपयोगकर्ता प्रभाव में अर्थ प्राप्त करता है, तकनीकी मेट्रिक्स में नहीं।

## मिलान जो झूठा आत्मविश्वास पैदा करता है```text
❌ Retry = güvenilirlik
✓ Retry, yalnızca geçici hatada ve idempotent işlemde güvenlidir.

❌ DLQ = kurtarma
✓ DLQ, inceleme ve replay sürecinin başlangıcıdır.

❌ Replay = her zaman güvenli
✓ Sürümleme ve yan etkiler ayrılmadan replay etkiyi tekrar üretebilir.

❌ Eventual consistency = rastgele gecikme
✓ Gecikme ölçülmeli, ürünle kabul edilmeli ve kullanıcıya açıklanmalıdır.

उत्पादन तत्परता की जाँच

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

यदि आप इनमें से प्रत्येक प्रश्न का उत्तर साक्ष्य के साथ नहीं दे सकते हैं, तो सिस्टम अप्राप्य लग सकता है; लेकिन यह अभी तक संचालन योग्य नहीं है।

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

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

उत्पादन वास्तुकला पहली बार में आने वाले संदेशों के बारे में नहीं है; यह इस बात से पता चलता है कि जब वे दो बार, देर से या अप्रत्याशित रूप से आते हैं तो आप कैसे व्यवहार करते हैं।