Event-Driven Commerce: एक Order के Promise से सत्यापित Outcome तक

सोमवार integration review में 1,900 eligible business operations हैं। एक consumer ने 1,412 applied confirm किए; 488 unresolved हैं: 480 recovery में, 8 investigation के लिए held । यह उदाहरण cohort है, customer incident नहीं। सवाल “synced” badge नहीं, कौन-सा काम बाकी, क्यों और उसका ज़िम्मेदार कौन है।

Event-driven design owner को business fact रिकॉर्ड करने देता है; दूसरे authorised हिस्से contracts से react करते हैं। जिम्मेदारियाँ स्पष्ट और dependencies कम उलझ सकती हैं। सही acceptance rules, durable delivery, सच्चे status और reconciliation फिर भी चाहिए। Freshness/recovery जरूरत पूरी हों तो nightly batch/polling भी वैध हैं।

Request, fact और reaction

Command owner से काम माँगता है: दो jackets reserve या refund issue । Owner permission/business conditions जाँचकर मना कर सकता है। Event रिकॉर्ड हुई occurrence है, जैसे OrderAccepted/PaymentCaptured । Consumer प्रतिक्रिया देता है। Fact का नाम आने वाले message की authenticity/validity या interpretation साबित नहीं करता; source/contract validate करें।

Events modular app के अंदर या broker से, synchronously या background में हो सकते हैं। Laravel event documentation queued listeners को explicit configuration बताती है, event class की automatic property नहीं। नया listener shared resources धीमे, fail या contract तोड़ सकता है। Govern/test करें; checkout कभी नहीं टूटेगा ऐसा वादा नहीं।

Jackets की वास्तविक states देखें

Teaching order 1042:दो JKT-M jackets USD 40 each, shipping USD 5, finance-approved tax USD 8;80+5+8=USD 93 । Assigned inventory cost USD 22/unit, total USD 44 । Currency, tax timing, valuation, delivery/revenue treatment explicit assumptions हैं, universal rules नहीं।

Warehouse 48 units, reserved 0 से शुरू। Final stock promise से पहले owning stock operation 2 reserve करता है, available 46 । Unconditional acceptance के बाद async reservation last unit oversell कर सकती है। अलग workflow हो तो success तक pending बताएं और expiry/cancellation/payment outcomes coordinate करें।

Table facts अलग करती है। Dispatch पर physical stock warehouse छोड़ता है; delivery बाद में। इस example के ownership terms में verified delivery/control transfer तक transit की 2 units business की हैं। Locations/states को दो बार deduct नहीं करना।

Fact/state	Stock/payment अर्थ	अलग प्रमाण
OrderAccepted	Warehouse 48; reserved 2; available 46	Valid reservation और durable acceptance
PaymentCaptured	Provider ने USD 93 capture किया	Settlement/bank receipt/accounting eligibility
ShipmentDispatched	Warehouse 46; reserved 0; transit 2	Physical handoff; transit cost दो बार नहीं
DeliveryConfirmed	यहाँ control transfer के बाद transit 0	Verified fulfilment/approved recognition

Recognition finance तय करता है

Payment authorisation, capture, provider settlement, bank receipt और earned revenue अलग facts हैं। IFRS 15 satisfied performance obligation और control transfer से recognition समझाता है जहाँ लागू हो। Actual policy/tax finance approve करे, developer ParcelDelivered subscribe करके अकेला न चुने।

सिर्फ़ इस example में capture customer advance/card-clearing receivable बनाता है; delivery goods/shipping obligations और approved tax point पूरा करती है। Dispatch पर assigned cost inventory-in-transit में गया। Journal fees, partial fulfilment, refunds/adjustments छोड़ता है; real policy अलग हो सकती है।

Capture: debit Card clearing 93, credit Customer advances 93 । Eligible delivery: debit Customer advances 93; credit Goods revenue 80, Shipping revenue 5, Tax payable 8 । साथ में debit Cost of goods sold 44, credit Inventory-in-transit 44 । Delivery debits 93+44=137; credits 80+5+8+44=137 । Handler balance enforce/test करता है। Balanced journal में date/account/amount/policy गलत हो सकती है।

Teaching entry	Debit	Credit
Capture	Card clearing 93	Customer advances 93
Eligible delivery	Customer advances 93	Goods 80 + shipping 5 + tax 8
Assigned delivered cost	Cost of goods sold 44	Inventory-in-transit 44

Owned change के साथ publication intent रखें

DB commit के बाद event भेजने से पहले process मरने पर gap रहता है। पहले publish और बाद में rollback हो तो झूठी occurrence घोषित हो सकती है। Transactional outbox business change/publication intent एक local transaction में रखता है; relay committed work भेजता है। Explicit semantics वाली उपयुक्त change-capture design भी संभव है।

Publish करके success लिखने से पहले relay crash हो तो duplicate आएगा। Outbox खास dual-write gap बंद करता है; storage failure, retention mistakes या bugs से event कभी नहीं खोएगा ऐसा नहीं। Pending work monitor, recoverable evidence और failure tests चाहिए। RabbitMQ publisher confirms और consumer acknowledgements अलग करता है। Broker acceptance हर consumer का effect पूरा होने का प्रमाण नहीं।

Customer order confirm से पहले क्या commit होना चाहिए तय करें। उपयुक्त notifications/projections defer हों, stock promise की correctness नहीं। Unresolved work को truthful pending state दें। Email-provider outage से accepted operation अनजाने में undo न हो।

Duplicate handling वास्तविक effect संभाले

Local DB effect में suitable unique processing key claim, business change और receipt एक transaction में commit करें। Concurrent duplicates atomically संभालें। Consumer/source-event identity/tenant scope रखें, अलग producers का समान ID दूसरे का काम न रोके। अलग messages एक business operation बता सकते हैं; operation-level uniqueness भी चाहिए हो सकती है।

Stripe duplicate/out-of-order webhooks document करता है, एक underlying occurrence के अलग event objects भी। Sender authenticate, सही account/environment map, durable receipt और actual contract रखें। DB का already-processed row external courier/email/refund को उसके साथ atomic नहीं बनाता।

External effect के durable operation reference और provider-supported idempotency/status lookup रखें। Ambiguous response में नया operation भेजने से पहले query । Bounded retry/backoff+jitter, attempt/age limits और owner हों। Invalid permission/data को correction/escalation चाहिए, अंतहीन retry नहीं। Dead-letter queue visible unresolved obligation है, business success नहीं।

Ordering, payload और replay की सीमाएं

CloudEvents 1.0.2 source/event identity/type/specification version का envelope देता है। उपयोगी हो तो अपनाएं; policy/trust/access तय नहीं करता। Versioned business schema, occurrence/recording time, entity/operation references और correlation तय करें। Producer-owned per-entity versions मदद करते हैं; payment/stock/delivery में automatic global order नहीं।

Timestamp universal ordering/dedupe key नहीं। Missing prerequisite पर consumer hold, authorised authoritative read या gap repair कर सकता है। पुराना event अंधाधुंध discard न करें; जरूरी effect बाकी हो सकता है। State machine के correction/cancellation/late-arrival rules लिखें।

हर authorised audience को न्यूनतम data । Order ID customer fetch permission नहीं; cost/payroll/address हर listener में न जाएं। जरूरत पर authorised versioned lookup/projection उपयोग करें; “never call back” universal rule नहीं। Queues, dead letters, history और operations interfaces सुरक्षित रखें।

Replay का उद्देश्य होता है। Same processing key पहले handled event skip कर सकती है, buggy code ने किया हो तब भी। Safe projection rebuild में controlled handler/version अलग हो सकता है; financial correction authorised repair है। सारे dedupe records मिटाकर live effects replay न करें। Event-driven integration से event sourcing या broker में permanent event store अपने आप नहीं मिलता।

Completed work का प्रमाण माँगें

OWASP logging guidance उपयोगी साथी है। Occurrence, consumer attempt, decision और actual result की protected evidence जोड़ें; sensitive data/retention सीमित हों। Ack पर गायब message पूरा audit trail नहीं। Event बचा होना consumer चला इसका प्रमाण नहीं।

Commit के पहले/बाद crash, duplicate concurrency, missing/out-of-order events, stale credentials, provider timeout और handler upgrades test करें। Oldest ready outbox/consumer work, outcomes, retry age, dead-letter owners और reconciliation gaps देखें। Nonzero duplicate-skip अकेला safety नहीं सिद्ध करता। Same scope/period/state के eligible records मिलाएं; order totals revenue/bank deposits के बराबर होना जरूरी नहीं।

सोमवार cohort: 1,900=1,412 confirmed+480 recovery+8 held । 488 unresolved reconciliation तक दिखते रहें; यह automatic 488 missing sales या मिनटों में posting का वादा नहीं। Operation reference और responsible owner green badge से उपयोगी हैं।

जिस consequence का delay स्वीकार्य हो उससे शुरू, owner/contract तय और recovery prove करके बढ़ें। तीन listeners का magic threshold या stock-first migration जरूरी नहीं। StoreConsole/किसी platform की enabled version/workflow में behaviour दिखवाएं, module diagram से full guarantees न मानें।

समीक्षा 5 नवंबर 2026 । Anichur Rahaman StoreConsole के निर्माता हैं। Order/cohort/accounting/stock शिक्षण उदाहरण हैं; approved business policies जरूरी।