I have a Voucher Service which listens to incoming sales, and updates vouchers based on what has been purchased/returned etc.
So we consume a SaleCompletedEvent, which may put vouchers into a 'redeemed' or 'available' state.
However it's not just sales which can change the state of a voucher, other things in the platform such as a VoucherRedeemedEvent may also arrive at any time and change the state of vouchers. In this scenario, the redemption of a voucher had nothing to do with a sale.
We therefore encounter racing issues across multiple Event topics: we can't guarantee SaleCompletedEvent and VoucherRedeemedEvent will arrive in the order they were created, and therefore we might process these events out of logical sequence and end up with a voucher in the wrong state.
As the number of events in my platform grows, I'm considering putting all these types of events (which can affect a shared resource) on the same message bus topic so that they'll at least arrive to consumes in the intended order. But what are other approaches used to solve this type of problem as platforms grow in the number of events, and thus racing complexity?
You may need to rethink the messages you send. If there's one event in the real life (a sale), then only emit one message.
If I got this right, if a voucher is used during a sale, you send a VoucherRedeemedEvent followed by a SaleCompletedEvent. I suggest that you only emit the SaleCompletedEvent, and you include the information that a voucher has been used into it. That will solve your problem.