Event-Driven Commerce: একটি Order-এর Promise থেকে যাচাই করা Outcome

সোমবারের integration review-তে 1,900 eligible business operation। নির্দিষ্ট consumer 1,412 টি applied নিশ্চিত করেছে, 488 টি unresolved: 480 recovery-র অপেক্ষায়, 8 তদন্তে held। এটি উদাহরণ cohort, customer incident নয়। Screen “synced” বলছে কি না নয়—কোন কাজ বাকি, কেন ও কে সমাধান করবেন সেটিই জরুরি।

Event-driven design-এ owner business fact রেকর্ড করেন, অন্য authorised অংশ defined contract দিয়ে প্রতিক্রিয়া করে। বাকি কাজ দৃশ্যমান ও dependency কম জটিল হতে পারে। Correct acceptance rule, durable delivery, সৎ status ও reconciliation তবু লাগে। Freshness/recovery business-এ মানালে nightly batch বা polling-ও বৈধ পছন্দ।

Request, fact ও reaction

Command owner-কে কিছু করতে বলে: দুই jacket reserve বা refund issue। Owner permission/business condition দেখে refuse করতে পারেন। Event রেকর্ড হয়ে যাওয়া occurrence—OrderAccepted বা PaymentCaptured। Consumer সেটিতে প্রতিক্রিয়া করে। Fact-এর নাম দিলেই incoming message genuine/valid বা ব্যাখ্যা সঠিক হয় না; source/contract validate করতে হবে।

Event modular app-এর ভেতর বা broker দিয়ে যেতে পারে; synchronous/background দুইভাবেই চলে। Laravel event documentation-এ queued listener explicit configuration; event class হলেই automatic নয়। নতুন listener shared resource ধীর, fail বা contract break করতে পারে। Governance/test লাগবে; checkout কখনো ক্ষতিগ্রস্ত হবে না—নিশ্চয়তা নয়।

Jacket-এর বাস্তব state অনুসরণ করুন

উদাহরণ order 1042-এ দুই JKT-M jacket প্রতিটি USD 40, shipping USD 5 ও finance-approved tax USD 8:80+5+8=USD 93 । Assigned inventory cost unit প্রতি USD 22, মোট USD 44 । Currency, tax timing, valuation, delivery/revenue treatment স্পষ্ট assumptions, universal retail rule নয়।

Warehouse-এ 48 unit, reserved 0 । Final stock promise-এর আগে owning operation 2 টি reserve করে, available 46 । Unconditional acceptance-এর পরে asynchronous listener reserve করলে last-unit oversell হতে পারে। আলাদা reservation workflow হলে success পর্যন্ত pending বলুন; expiry/cancellation/payment outcome coordinate করুন।

Table-এ facts আলাদা। Dispatch-এ physical stock warehouse ছাড়ে, delivery পরে। এই উদাহরণের ownership term-এ verified delivery-তে control transfer না হওয়া পর্যন্ত transit-এর 2 টি business-এরই। একই stock দুই ধাপে 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; owned transit double expense নয়
DeliveryConfirmed	এখানে control transfer হলে transit 0	Verified fulfilment ও approved recognition

Recognition finance ঠিক করবে, delivery label নয়

Payment authorisation, capture, provider settlement, bank receipt ও earned revenue আলাদা fact। IFRS 15 performance obligation পূরণ ও control transfer দিয়ে recognition ব্যাখ্যা করে যেখানে standard প্রযোজ্য। Actual policy/tax treatment finance approve করবেন; developer ParcelDelivered subscribe করে একা বাছবেন না।

শুধু এই উদাহরণে capture-এ customer advance ও card-clearing receivable ধরি; delivery-তে goods/shipping obligation ও approved tax point পূরণ। Dispatch-এ inventory owner assigned cost inventory-in-transit-এ নিয়েছেন। Journal-এ fee, partial fulfilment, refund/অন্য adjustment নেই; 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 debit 93+44=137; credit 80+5+8+44=137 । Accounting handler balance enforce/test করবে। Balanced journal-এও ভুল date/account/amount/policy থাকতে পারে।

উদাহরণ 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 হওয়া পরিবর্তনও ঘোষণা হতে পারে। Transactional outbox একই local transaction-এ business change/publication intent রাখে; relay committed কাজ publish করে। Explicit semantics-সহ অন্য উপযুক্ত change-capture design-ও হতে পারে।

Publish-এর পরে success record-এর আগে relay crash করলে duplicate আসে। Outbox নির্দিষ্ট dual-write gap বন্ধ করে; storage failure/retention mistake/bug-এ কখনো event হারাবে না—এমন নয়। Pending work monitor, recoverable evidence ও failure test লাগবে। RabbitMQ publisher confirm ও consumer acknowledgement আলাদা করে। Broker নিয়েছে মানে সব consumer effect শেষ নয়।

Customer order confirm-এর আগে কী commit করতে হবে ঠিক করুন। উপযুক্ত notification/projection defer করুন, stock promise-এর correctness নয়। Unresolved কাজের truthful pending state দিন। Email provider down হওয়ায় accepted operation অনিচ্ছায় undo হবে না।

Deduplication প্রকৃত effect-কে ঢাকুক

Local DB effect-এ উপযুক্ত unique processing key claim, business change ও processing receipt একই transaction-এ commit করুন। Concurrent duplicate atomically সামলান। Consumer/source-event identity/tenant scope ধরুন; ভিন্ন producer-এর একই ID অন্যের কাজ suppress না করুক। আলাদা message একই business operation জানাতে পারে, তাই operation-level uniqueness-ও প্রয়োজন হতে পারে।

Stripe duplicate/out-of-order webhook নথিভুক্ত করেছে—এক occurrence-এর আলাদা event object-ও হতে পারে। Sender authenticate, সঠিক account/environment map, durable receipt ও actual contract মানুন। আপনার DB-তে already-processed row external courier/email/refund-কে একই atomic transaction বানায় না।

External effect-এ durable operation reference ও provider-supported idempotency/status lookup ব্যবহার করুন। Ambiguous response-এ নতুন operation-এর আগে query। Jitter-সহ bounded retry/backoff, attempt/age limit ও owner রাখুন। Invalid permission/data-এ correction/escalation, endless retry নয়। Dead-letter queue দৃশ্যমান unresolved দায়িত্ব, successful business processing নয়।

Ordering, payload ও replay-এর boundary

CloudEvents 1.0.2 source/event identity/type/specification version-এর common envelope দেয়। প্রয়োজনমতো নিন; accounting policy/trust/access অধিকার নির্ধারণ করে না। Versioned business schema, occurred/recorded time, entity/operation reference ও correlation ঠিক করুন। Producer-owned per-entity version সাহায্য করে; payment/stock/delivery service মিলিয়ে automatic global order নেই।

Timestamp universal ordering/dedupe key নয়। Prerequisite না এলে consumer hold, authorised authoritative state read বা gap repair করতে পারে। পুরোনো বলে blind discard নয়—প্রয়োজনীয় effect থাকতে পারে। Actual state machine অনুযায়ী correction/cancellation/late arrival ঠিক করুন।

প্রতি authorised audience-কে minimum data দিন। Order ID মানেই customer fetch permission নয়; cost/payroll/address সব listener-এ fan-out নয়। প্রয়োজন হলে authorised versioned lookup/projection ব্যবহার করা যায়; “never call back” universal rule নয়। Queue, dead letter, event history ও operations interface protect করুন।

Replay-এর উদ্দেশ্য থাকে। একই processing key আগের handled event skip করবে, buggy code handle করলেও। Safe projection rebuild-এ controlled নতুন handler/version লাগতে পারে; financial correction authorised repair। সব dedupe record clear করে live effect replay নয়। Event-driven integration মানেই event sourcing বা broker-এ permanent event store নয়।

সম্পন্ন কাজের প্রমাণ চান

OWASP logging guidance integration design-এর সহায়ক। Occurrence, consumer attempt/decision/actual result linked protected business/audit evidence বানান; sensitive data সীমিত ও retention নির্দিষ্ট। Ack-এর পরে message মুছে গেলে তা complete audit trail নয়। Event রাখলেও consumer চলেছে প্রমাণ হয় না।

Commit-এর আগে/পরে crash, concurrent duplicate, missing/out-of-order event, stale credential, provider timeout ও handler upgrade test করুন। Oldest ready outbox/consumer work, outcome, retry age, dead-letter owner ও reconciliation gap মাপুন। Nonzero duplicate-skip একা সব effect safe প্রমাণ নয়। একই scope/period/state-এর eligible record তুলনা করুন; order total revenue/bank deposit-এর সমান হতেই হবে নয়।

সোমবারের cohort: 1,900=1,412 confirmed+480 recovery অপেক্ষায়+8 held। 488 unresolved reconcile পর্যন্ত দৃশ্যমান থাকে; এটি automatic 488 missing sale নয়, কয়েক মিনিটে post হবে নিশ্চয়তাও নয়। Operation reference ও responsible owner green badge-এর চেয়ে কাজে লাগে।

যে consequence-এর delay গ্রহণযোগ্য সেটি দিয়ে শুরু, owner/contract নির্ধারণ ও recovery প্রমাণ করে এগোন। তিন listener-এর magic threshold বা stock-first migration বাধ্যতামূলক নয়। StoreConsole/যেকোনো platform-এর enabled version/workflow-এ আচরণ দেখুন, module diagram থেকে full guarantee নয়।

পর্যালোচনা 5 নভেম্বর 2026 । Anichur Rahaman StoreConsole-এর নির্মাতা। Order/cohort/accounting/stock উদাহরণ শিক্ষামূলক; approved business policy লাগবে।