Great article! One issue I commonly see in the wild is non-deterministic transformations when converting internal events to external messages for a broker. Could you walk through how to handle determinism in this context and apply it to the example above?

Thanks kingsdad, glad that you liked it!

I'll try to schedule the follow up, just to double check, by issues with determinism, do you mean cases like:
- how to get the state at revision on which the internal event was published not to use its later or earlier accidentally?
- how to setup queues/topics topology to get the ordering guarantee on the side of publisher?
- some other scenarios? 🙂

One common example is publishing an external event through a message broker such as Azure Service Bus, where you need a **deterministic `MessageId`** so that retried publishes don’t create multiple distinct messages. I frequently see publishers use `Guid.NewGuid()`, which means each retry gets a new ID and makes it harder for downstream consumers to detect and safely handle duplicates.

Related to that, how do you think about *when* to perform the external event transformation—should we materialize and persist the transformed event durably before publishing, or is it acceptable to compute it on the fly at publish time?