Reliable messaging

As far as I understand MT in comparison to NServiceBus does not support reliable messaging out of the box. (correct me, if I’m wrong, I’d be very happy to be mistaken).

Yet I see an option of using the underlying RabbitMQ for that purpose. Here is the workflow:

• do some biz rules
• generate special correlation id
• store this id in db
• publish a message
• commit transaction

But instead of going to consumers message first goes to a special ‘loopback queue’, where it is processed by the sender/publisher part or by some dedicated service which has a task of looking inside DB for a corresponding correlation id, and in case of success putting message in correct exchanges.

[joshmouch]

I’m comparing CAP to MassTransit, and this will be a deciding factor for me. Can you provide a quick code example of how this Outbox pattern would be implemented with Azure ServiceBus and SQL Server? I’m not familiar enough with Mass Transit to take your awesome diagram and put it into practice.

[alexeyzimarev]

My last two cents in this issue.

NServiceBus reliable messaging (Outbox) only works when you use the same database and access method (framework) for your usual database operations performed from inside the message consumers and for the outbox persistence itself. This database also needs to support transactions that span across several operations. It means that NSB supports this feature only for NHibernate, SQL (ADO.NET), RavenDb and ServiceFabric, using the synchronized storage.

I actually think it can be done with MassTransit by creating a persisted outbox filter. The database connection and transaction can be put into the context so they can be used inside a consumer.

This is the NSB implementation, it really looks like a filter: