QUICK OVERVIEW
What to take away from the article
- Every important event needs an identity and a traceable result.
- The retry must not repeat the business effect.
- Errors should have an owner, a resolution deadline and the possibility of safe recovery.
Determine which system is the source of truth
The e-shop accepts the order, the warehouse reserves the goods and the accounting system manages the document. If each system can change everything without rules, conflicts arise. For each field, determine the owner: who decides the price, payment status, availability and shipping status. Other systems receive a verified change or send a request to execute it.
For several companies, the identification must also include the company. The same order number can exist in two separate agendas. Therefore, the link between records should not only be based on the number displayed to the customer. You need internal identifiers and mapping between systems. The business framework describes the article about warehouse and ERP connected e-shop.
A webhook is a notification, not a guarantee of completion
The webhook notifies the other application of an event, such as a successful payment. The recipient must verify the sender and the data. Stripe's documentation warns about signature verification, the possibility of duplicate events, and that delivery order may not be guaranteed. These features must be taken into account in the design of each specific integration according to its documentation.
We recommend first securely enqueuing the event before confirming its receipt. The business processing itself can continue separately. The system thus distinguishes between received, processed and error events. It's not enough to return a successful response and hope the next step goes through. If the commit goes out before it is persisted, the outage may lose the event.
Idempotency: same instruction, same effect
Idempotency means that safely repeating the same instruction will not create a second order, reservation or invoice. In practice, the recipient remembers the event's unique identifier and the processing result. At the same time, it must also protect the business operation, since two different technical events can describe the same change.
Imagine an outage after creating an order in ERP, but before the confirmation is delivered back to the e-shop. The e-shop will try the request again. The correct result is to find the existing binding and return the same order, not create another one. The check must also withstand two simultaneous attempts; simple "find first then create" without concurrency protection may not be enough.
Delayed events must not set the order back
The "order received" message may arrive only after the "paid" message. If everyone overwrites the state without checking, the old information will erase the newer result. Use the state transitions allowed and the available version or time of the event. In case of conflict, load the current state from the source system.
Cancellation and refund are separate events. Do not delete the history of successful sales; note the subsequent change. The same principle applies to partial shipping and split orders. One universal state of "done" is often not enough for storage, transport and documents.
| Area | Postup | What to check |
|---|---|---|
| Repeated webhook | The existing result, without a second operation. | Number of reservations and documents. |
| Dropout after registration | Repeat will find an already created order. | Binding of identifiers between systems. |
| Wrong order | An older status will not overwrite a confirmed newer one. | Allowed transitions and history. |
| Incorrect data | The recording stops with a specific reason. | Responsible person and safe repair procedure. |
Automatic repetition and working list of exceptions
A temporary outage can be resolved by repeating with increasing distance. However, repetition alone will not correct a missing rate, an unknown product, or the wrong company. Divide technical errors into temporary and substantive. After the set limit, the event must go to the list for resolution, not run indefinitely.
The manager needs to see the number of stuck orders, their age, value and reason. The worker needs a specific next step and access to relevant documents. After the repair, only the necessary part of the process should be restored. We discuss the design of the morning report in the multi-business dashboard article.
Also check what hasn't arrived
Event monitoring will detect an error message, but may not catch a completely missing event. Therefore, add regular reconciliation: web orders vs. ERP, confirmed payments vs. paid orders, and shipping vs. stock movements. Exceptions must be explainable and attributable to a person or a repair process.
Run the pilot on a single stream with limited scope. Measure processing time, manual intervention rate, number of duplicates and number of outstanding differences. Extend automation only when the outage can be safely recovered. A reliable connection brings savings precisely because the company does not have to manually check every day whether something has been lost.
