[Diggsey]

The timestamp in this case would be when the message was added to the queue, not the timestamp of the transaction which triggered the event.

If two transactions are non-causal, it doesn't matter which order the events arrive in the queue, but once the message is in the queue, the order is fixed.

> Or if you have ≥$maxCount number of events changed the same exact timestamp?

Use a sufficiently precise timestamp that this doesn't happen, or add a counter in the low bits. The only reason to use a timestamp rather than a simple incrementing counter is to make it more convenient for recipients to re-request historical events (eg. I want to replay all events since yesterday) and to make debugging easier, since with a counter it's a bit meaningless.

The timestamp is not meaningful for the actual event, its only purpose is to specify where this event sits in the total order.