Strict Message Ordering Recipe

[jeremydmiller]

I think this is potentially a combination of:

• 784 - "Sticky" listeners / virtual actors

• 783 - First class subscriptions from Marten

• 722 - Option for a strictly ordered outbox alternative

In one quick way, users should be able to specify that they want a certain message or group of messages be handled in strict order. I think it's going to have to include the endpoint as well. By saying "make this strictly sequenced" it should configure everything that needs to happen. So any in memory TPL blocks have to be sequential. Retries have to be different because you can't skip messages.

[erdtsieck]

It would be nice if you group messages by some groupid and keep them sequential per group

[jeremydmiller]

We already support that for Azure Service Bus. Doing the sticky listener would help too though

[woksin]

I've mentioned it before, but what @erdtsieck said would be nice for use cases we have as well. The group id would in many cases be an event source id or aggregate id, something like that. And have that supported for both local- and non-local queues with and without persistence.

Other than that, the virtual actors thing is very useful (btw have you ever looked into building on too of an actor model framework, like Akka or Proto.Actor?)

First class subcsription from Marten, can be very useful for event sourcing applications

[jeremydmiller]

I have zero intention of ever trying to match AkkaDotNet in terms of the virtual actor approach, but just a tiny bit would be useful. I think Proto.Actor and AkkaDotNet both have awkward usability, so I'm a hard no on that one.

I really don't think it would be that hard to carry the aggregate id through to the group id. Especially with the first class subscription idea.

[lcorneliussen]

Would be usful for both sagas and aggregate handlers to ensure that only one message is handled at the same time. Now we rely on optimistic concurrency - which doesn’t look very nice in the logs 😆