Support sees Paid. The warehouse sees Packed. The customer sees a dispatch email.
Before declaring that the systems disagree, we should ask whether they’re answering the same question. A payment state, a packing state and a shipment state are different facts. They may all be correct while the overall order still needs attention.
The harder problem is knowing how those facts relate and spotting when an expected update never arrives.
Let’s use a fictional subscription business with checkout, fulfillment and support tools. The goal is one understandable customer journey, rather than forcing every application to use an identical status word.
Give each important fact an owner
A shared label can hide different meanings. Processed might refer to payment, warehouse preparation or a support request somebody has finished reading.
Decide which system establishes each fact and how the others learn about it.
Payment and fulfillment need separate evidence
A successful charge doesn’t prove that stock was allocated or a parcel left the building. A created shipping label doesn’t necessarily prove carrier collection.
Keep the authoritative references and the relevant times. Support should be able to tell what actually happened without treating the latest email as the official state of the universe.
Partial fulfillment can complicate the picture further. One order may have more than one shipment or a later adjustment. A single Shipped checkbox may be too small a home for that reality.
The data model should reflect the business’s actual units of work. Otherwise, staff will keep the missing distinctions in a spreadsheet with a name like Final Status Real.
Events can notify without completing the whole process
Martin Fowler’s discussion of event-driven systems distinguishes several patterns, including notifications that tell another system something changed.3
That notification doesn’t automatically establish every downstream action. A payment event can start further work without proving that work has finished.
Name events according to facts that occurred, and define any requested actions separately. OrderPaid and PleaseDispatchOrder express different things.
Clear meanings make it easier to understand what a receiving application is expected to do and what evidence would show that it did it.
Our integrations and AI team builds connections that keep records in step.
Design for the update that arrives awkwardly
Messages can arrive more than once, late or in a different order from the business events they describe. The integration needs rules for those conditions.
The customer should not become responsible for discovering which notification won the race.
Make duplicates harmless where they can recur
Record message identities and protect the relevant business change so repeated delivery doesn’t create repeated effects.
Where appropriate, save the processing record with the local state change in the same transaction. A suitable uniqueness constraint can help with concurrent copies.
External effects need their own protection. Preventing a duplicate local row isn’t automatically the same as preventing a second shipment request.
The application should also recognize stale updates where the underlying system provides suitable versions or authoritative state. An old Packed event should not blindly undo a later confirmed dispatch.
Keep a durable record of outgoing work
An outbox can store the intent to publish a message alongside the local business change. A separate publisher continues the handoff.
That addresses a particular gap: saving a fact and then failing before remembering to tell another system. It doesn’t make publication and all downstream effects one indivisible action.
If this was useful, try A subscription renewal is also a promise to the kitchen.
Expect retries and monitor unresolved work. A reliable record is useful only if something continues processing it and someone notices when it cannot.
We can give the messenger a notebook. We still need a plan for the day the messenger doesn’t arrive.
Reconcile the expected story with the actual one
Event delivery is the normal route. Reconciliation provides another way to find gaps.
For the fictional business, compare relevant records using stable identifiers. Look for cases such as a payment with no expected fulfillment work, a shipment with no corresponding customer status or an update stuck beyond an agreed period.
Treat those as investigations, not automatic evidence that one system is wrong. Business exceptions may be legitimate.
Give support a clear view of the facts, their sources and unresolved steps. Make manual recovery scoped and safe, with a record of what was done.
Then rehearse a duplicate message, a delayed event and an interrupted handoff. Check whether the same customer order remains understandable throughout.
The aim isn’t three applications saying the same word at the same instant. It’s a team that can explain where the order is and help it continue.
Paid, packed and shipped can all keep their jobs. They just need to stop sharing an office badge.