Hi, curious if anyone has any strategies for handling the order of messages being processed in cases of failures/retries.
For instance…if an account can be disabled then later re-enabled. If we had the following messages:
The end user would like the account to ultimately be disabled.
If the service temporarily failed, you could wind up in a scenario where the first message was processed, then the other two wind up in the queue…
Net effect would be the account remains enabled.
Multiple messages come in to edit the same account. The first could overwrite the second depending on failures + how the retry logic shakes out. I suppose you could assign the record a unique GUID and prevent the message from succeeding if its GUID doesn’t match the one in the db. I’m that case, the first one to succeed would update the record’s GUID, causing the second one to fail permanently. It would wind up in the dead letter queue as unprocessable, and you wouldn’t have the capacity to notify the user due to the fire and forget nature of messages.
Both scenarios seem challenging. Any ideas?