If you are using "trigger events" for security reasons, wouldn't it be more appropriate to send an ephemeral "eventID" rather than an actual "orderID"? Otherwise you may be leaking order IDs, which could potentially carry useful information for an attacker.
Any exposed information should be exposed deliberately. Although I didn't cover it in this post. In my event-driven setups, events are always wrapped in a message envelope data structure. Where a message is contains 1) the event/payload and 2) a set of headers to carry more "system-y" data, like time of recording, system of origin, and other observability related information. The event ID is one of those values.
In general you need to send something which can be used to look up the data in a more appropriate (e.g. authenticated or deletable) system. A true event ID may not be available until after the message is successfully produced; anything generated before that is tantamount to the order ID anyway.
Note that "sensitive" in this case can mean a persistence/retention boundary and not a security boundary.
I'm not sure. We have distributed systems of this type at $JOB and a correlation ID that is generated on user action and attached to every event in the chain (regardless of service) is plenty. I don't think we've ever needed to look at anything so specifically that a unique event ID for each event would have been helpful.
