Respond meaning by sending a receipt back the to the original sender? Before. Because then the sender can assume it never arrived if it never receives a respon

Respond meaning by sending a receipt back the to the original sender? Before. Because then the sender can assume it never arrived if it never receives a response and can try again. If the receiver has already processed/recorded it, it goes through the motions again, but in an idempotent way that doesn't break anything by performing the action twice (or more). Eventually, the sender will get the response that it doesn't need to try again and it will reach resolution. This is an extension of the two generals problem and can be totally resolved by using an idempotent design. However, you can never guarantee a resolution is reached on any given attempt, and that is by design. My personal favorite approach is not using timestamps. The sender attaches a unique GUID, and the receiver records that GUID along with the processed event record. If the receiver sees it 100 times, it doesn't matter. It will do nothing the next 99 times, and tell the sender that it performed the task even without actually repeating it. Eventually the sender will record that and stop asking.