In an order platform, purchase confirmation can trigger shipment tracking, volume analysis and a notification. Each receiving application uses the event identifier to detect duplicate delivery. It also checks the version before updating its own records.
The exchange contract establishes those properties. It allows applications to evolve without requiring every participant to run the same process at the same moment. The following example follows an order from its initial write to a read view; it illustrates a design mechanism without describing a particular organisation.
The scope of API confirmation
The API receives the confirmation request and applies the order rules. A successful response can confirm that the order was recorded without implying that every receiving application has already been updated. This distinction belongs in the contract exposed to the caller.
The event records that an order has been confirmed. It contains an event identifier, the order reference, its version and the fields needed by receiving applications. Shipment tracking and volume analysis can consume the same event and update their own data.
Connect the write with publication
Saving the order and sending a message as two independent operations leaves an inconsistency window. The write can succeed while publication fails. A transactional outbox stores the order and the event awaiting publication within one database transaction. A relay subsequently transmits the stored events. The AWS description of the outbox pattern explains this separation and the need to handle repeated delivery.
The relay can publish a message and stop before recording its progress. The event will then be sent again. The consumer retains a record of processed identifiers and applies its update consistently with that record. The business effect therefore depends on receiver processing as well as transport guarantees.
Preserve version meaning
The read projection stores the order fields needed for queries, its status and its update time. It can be rebuilt from event history or reinitialised from the system of record. Separating write and read models, known as CQRS, allows read queries to be optimised separately from order transactions. The publishing pipeline keeps them synchronised.
When a correction arrives before an older event, the order version lets the consumer reject stale state or detect a missing version. Kafka preserves message order within a partition. The partition key must therefore group the events whose order must be preserved, using the mechanisms described in the Apache Kafka documentation.
Schema evolution requires similar attention. Adding an optional field and changing an existing field’s meaning have different effects. The contract defines absent values, accepted older versions and conversion rules. A technically readable message can still be semantically incompatible.
Make exchange progress observable
Monitoring measures events recorded in the outbox, published to the broker and applied to read projections. It also tracks publication lag, transformation errors and messages in the error queue. These measurements distinguish transport delay from an update rejected by the receiving application.
In this example, the order retains its reference state while the read view reports the version it has incorporated. Applications can then evolve separately while sharing a clear rule about what a value means and when it becomes visible.