An order, a captured payment and a delivered parcel are different facts. Connect them with reliable publication, scoped consumers and accountable recovery.
Autor
Anichur Rahaman
Monday’s integration review lists 1,900 eligible business operations.1,412 are confirmed applied by a particular consumer, leaving 488 unresolved: 480 awaiting recovery and 8 held for investigation. This is an illustrative cohort, not a customer incident. The useful question is which work is owed, why it is waiting and who will resolve it—not whether a screen says “synced”.
Event-driven design lets an owner record a business fact and other authorised parts react through defined contracts. It can make obligations visible and reduce tangled dependencies. It still needs correct acceptance rules, durable delivery, truthful status and reconciliation. A nightly batch or polling process can also be legitimate when its freshness and recovery meet the business need.
A command asks an owner to do something: reserve two jackets or issue a refund. The owner checks permission and business conditions and can refuse. An event describes an occurrence already recorded, such as OrderAccepted or PaymentCaptured. A consumer reacts to it. The fact’s name does not prove that an incoming message is genuine, valid or correctly interpreted; consumers must validate source and contract.
Events may stay inside a modular application or cross a broker. They can execute synchronously or through background work. Laravel’s event documentation makes queued listeners an explicit configuration, not an automatic property of an event class. A new listener can still slow shared resources, fail or break a contract. Govern and test it rather than promising that checkout can never be affected.
Teaching order 1042 buys two JKT-M jackets at USD 40 each, with USD 5 shipping and a finance-approved tax amount of USD 8:80+5+8=USD 93. Assigned inventory cost for this example is USD 22 per unit, USD 44 total. Currency, tax timing, valuation, delivery and revenue treatment are explicit assumptions, not a universal retail rule.
The warehouse starts with 48 units, none reserved. The owning stock operation secures a reservation of 2 before a final stock promise, leaving 46 available. An asynchronous listener that reserves only after unconditional acceptance can oversell the last unit. If reservation is a separate workflow, report pending until it succeeds and coordinate expiry, cancellation and payment outcomes.
The table distinguishes the business facts. Shipment dispatch moves physical stock out of the warehouse; delivery confirmation is later. Under this example’s ownership terms, the business still owns the 2 units in transit until verified delivery transfers control. Those locations and states must not be deducted twice.
| Fact or state | Stock/payment meaning | What still needs its own proof |
|---|---|---|
| OrderAccepted | Warehouse 48; reserved 2; available 46 | Valid reservation and durable order acceptance |
| PaymentCaptured | USD 93 captured by provider | Settlement/bank receipt and accounting eligibility |
| ShipmentDispatched | Warehouse 46; reserved 0; transit 2 | Physical handoff; owned transit stock not expensed twice |
| DeliveryConfirmed | Transit 0 after control transfers here | Verified fulfilment and finance-approved recognition |
A payment authorisation, capture, provider settlement, bank receipt and earned revenue are different facts. IFRS 15 explains recognition through satisfied performance obligations and transfer of control where that standard applies. Finance must approve the actual policy and tax treatment; a developer should not select it merely by subscribing to ParcelDelivered.
For this teaching example only, assume capture creates a customer advance and card-clearing receivable; delivery satisfies the goods/shipping obligations and the approved tax point. The inventory owner has moved the assigned cost into inventory-in-transit at dispatch. The journal illustration below excludes fees, partial fulfilment, refunds and other adjustments; real policy may differ.
At capture, debit Card clearing 93 and credit Customer advances 93. At eligible delivery, debit Customer advances 93; credit Goods revenue 80, Shipping revenue 5 and Tax payable 8. Also debit Cost of goods sold 44 and credit Inventory-in-transit 44. Delivery debits 93+44=137; credits 80+5+8+44=137. Balance is an invariant the accounting handler enforces and tests. A balanced journal can still use the wrong date, account, amount or 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 |
There is a gap if a database commit succeeds and the process dies before sending its event. Publishing first can announce a change that later rolls back. A transactional outbox stores the business change and publication intent in one local transaction; a relay then publishes committed work. Another suitable change-capture design may also be used with explicit semantics.
The relay can publish and crash before recording success, producing a duplicate. An outbox closes a particular dual-write gap; it does not guarantee no event can ever be lost through storage failure, retention mistakes or operational bugs. Monitor pending work, retain recoverable evidence and test those failures. RabbitMQ distinguishes publisher confirms from consumer acknowledgements: broker acceptance does not prove every business consumer completed its effect.
Choose what must be committed before confirming the customer’s order. Defer suitable notifications or projections, not the correctness of the stock promise. Show a truthful pending state for work that remains unresolved, and do not make an email-provider outage undo an already accepted business operation accidentally.
For a local database effect, claim an appropriate unique processing key and commit that claim, the business change and processing receipt together. Handle concurrent duplicates atomically. Include consumer, source/event identity and tenant scope as appropriate; do not let two unrelated producers sharing an ID suppress each other’s work. Separate messages can describe the same business operation, so operation-level uniqueness may also be needed.
Stripe documents duplicate and out-of-order webhook delivery, including separate event objects for the same underlying occurrence. Authenticate the sender, map the right account/environment, store a durable receipt and use the actual provider contract. An “already processed” row in your database cannot by itself make an external courier booking, email or refund atomic with it.
For external effects, retain a durable operation reference and use the provider’s supported idempotency and status lookup. If the response is ambiguous, query before sending a new operation; bound retries and backoff with jitter, an attempt/age limit and an owner. Invalid permissions or data need correction/escalation, not endless retries. A dead-letter queue is a visible unresolved obligation, not successful business processing.
CloudEvents 1.0.2 offers a common envelope with source and event identity, type and specification version. Adopt it where useful; it does not define your accounting policy, trust or access rights. Define a versioned business schema, occurrence and recording times, relevant entity/operation references and correlation. Per-entity versions can help where the producer owns that ordering; there is no automatic global order across payment, stock and delivery services.
A timestamp is not a safe universal ordering or duplicate key. A dependent consumer may need to hold a missing prerequisite, read authorised authoritative state or repair a gap. Do not discard an older event blindly if it carries a still-required effect. Define correction, cancellation and late-arrival rules for the actual state machine.
Send the minimum data needed by each authorised audience. An order ID is not permission to fetch the customer; cost, payroll or addresses must not fan out to every listener. A consumer can use an authorised versioned lookup or projection where needed; “never call back” is not a universal rule. Protect queues, dead letters, event history and operational interfaces.
Replay has a purpose. The same processing key may correctly skip a previously handled event, including one handled by buggy code. Rebuilding a safe projection may use a separate controlled handler/version, while a financial correction needs an authorised repair. Never clear all deduplication records and replay live side effects blindly. Event-driven integration also does not require event sourcing or guarantee that a broker retains a permanent event store.
OWASP’s logging guidance is a useful companion to integration design. Build protected business/audit evidence linking occurrence, consumer attempt, decision and actual result, with restricted sensitive data and retention. Queue messages that vanish after acknowledgement are not a complete audit trail, and even a retained event does not prove its consumer ran.
Test crashes before/after commit, duplicate concurrency, missing/out-of-order events, stale credentials, provider timeouts and handler upgrades. Track oldest ready outbox/consumer work, outcomes, retry age, dead-letter ownership and reconciliation gaps. A nonzero duplicate-skip count alone does not prove all effects are safe. Compare eligible records for the same scope, period and state; order totals need not equal recognised revenue or bank deposits.
Return to Monday’s cohort: 1,900=1,412 confirmed+480 awaiting recovery+8 held. The 488 unresolved operations stay visible until reconciled; they are not automatically 488 missing sales or a promise to post within minutes. A retained operation reference and responsible owner are more useful than a reassuring green badge.
Start with a consequence whose delay is acceptable, define its owner/contract and prove recovery before expanding. There is no magic threshold of three listeners or mandatory stock-first migration. Evaluate StoreConsole or any platform by demonstrating these behaviours in its actual enabled version and workflow—not by inferring full guarantees from a module diagram.
Reviewed 5 November 2026. Anichur Rahaman is the creator of StoreConsole. Orders, cohort counts, accounting and stock examples are illustrative and require approved business policies.
Über den Autor
Anichur Rahaman
Weiterlesen
