Platform capability · Reliable Event Delivery
An event is saved with the change that caused it, then delivered at least once and safely retried
The event is written in the same database transaction as the business change. It is then delivered at least once. Each event carries a key that makes a repeat safe, delivery pauses and retries when the message broker is unavailable, and messages that cannot be delivered are kept so they can be reviewed and sent again. If delivery is interrupted, the saved event stays available for retry. Consumers use the key to avoid applying the same change twice.
A common pattern is to save a record and then publish an event about it. If the process stops between the two steps, the data has changed and no other service knows. Or the event is sent twice and a charge is applied twice. The platform closes this gap. The event is written in the same transaction as the change, so both are saved or neither is. A separate delivery step then sends the event.
Each event carries a key that consumers use to reject a repeat. When the message broker is unhealthy, delivery pauses and retries. Messages that use up their delivery attempts go to a failed-message queue, where they can be inspected and replayed.
The shared SDK implements this pattern. Apps write events through the SDK. The dispatcher handles retries, pauses when the broker is unavailable, and failed messages. Consumers still check the key on each event, because delivery is at least once.
A solution architect will demo the live service against your domain model.