Strategies for handling message (dis)order

[brett]

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:

-Disable account
-Enable account
-Disable account

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…

-Disable account
-Enable account

Net effect would be the account remains enabled.

Example 2…
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?

[Sean_Farmar]

@brett

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.

Sounds like you are describing a collaborative domain issue, where multiple actors can modify the same resource and the order is important.
In those scenarios we can look at using insert only strategies and read and write logic like using the sent date and a guide to keep the correct order of the message/event, also a little like idempotent code, if I saw this message before, or It is older than the latest one, I just insert it but ignore it’s value when calculating the correct state…

Does that make sense?