The idea of using multiple differently partitioned stages
We an achieve the same level of guarantees of a transaction inside an event ueue. For an accounting balance ovement we can first create an evdent dtating that we need t move data from one account to another. His transaction is given a uique d. Another process takes this message and creates a debit event and a credit event with te assigned id. Other swrvices can be listening to this messages and perform the necessary movements. If there was a constraikn on he balance on an account stating that it cant be lower than zero, a similar approach of the one use for keepimg the uniqueness of usernames can be used. A message should be reated askimg for permission to perform the debit. Then we wait for that message to be on the queue. Lastly we check flr a confirmation message. We can track this message through its ransactionid. If everything checks out we confirm the movement.
This works because ll the transactions of a given account are routed to the same partition where they are process in order. This avoids race onditions.
