CODEWITHSUNDEEP
masstransit
ForteUnited
ForteUnited

Reputation: 43

MassTransit Transactional Outbox Redelivery

I am looking to use MassTransit in my application for a variety of use cases. One use case is to handle in app "domain events". In this use case I have some business data that is changing for an aggregate and want to queue up some domain events that will be handled by the same app but in an eventually consistent manner and outside the context of the current HTTP request. These aren't 'integration events', and by this I mean I don't think they need to go to a broker as the consumer of these events is this same application.

I have been trying to follow the MassTransit doc on outbox

  1. https://masstransit.io/documentation/patterns/transactional-outbox

So far I have the outbox working with my EF Core dbcontext just fine. I also have the events being delivered to the consumer (again in the same app) using the "In Memory" transport. The issue I'm having, and I suspect it is because this is the default behavior of the in memory transport is that once the message is delivered the consumer, regardless of whether the consumer completes successfully or not, the message is removed from the outbox table in SQL Server.

So essentially, let's say as the consumer is processing the message/event after it has been delivered to it and in the middle of processing the machine/container goes down/terminates. The message is basically gone/lost since it is no longer in the outbox table in SQL Server.

Is there a way to layer in some type of guarantee here when using the in memory transport? Do I need to use a broker and a different transport here for in app domain events? Any guidance here is much appreciated.

Additionally, I think this article is similar to my issue but I still don't understand what the solution is. https://masstransit.io/documentation/patterns/in-memory-outbox

I have tried using the .UseScheduledRedelivery but either didn't configure it correctly or it doesn't do anything with the In Memory transport because I haven't seen any change in behavior.

Upvotes: 0

Views: 606

Answers (1)

Yannic Hamann
Yannic Hamann

Reputation: 5225

As you guessed correct real/distributed messaging as opposed to in-memory events would be overkill for processing domain events, since you just need to process those events within the same process.

The EShop (On Container) reference app from Microsoft uses MediatR for domain events. For Integration Events they built their own abstraction with APIs directly from RabbitMQ and Azure Event Bus. This Integration Event layer implementation could be swapped out with a service bus like Mass Transit. In fact, this is how it is recommended by the PDF.

I recommend reading the section Resiliently publishing to the event bus for integration events. For domain events, they chose to wrap everything in-process related in one atomic transaction. If it fails no mitigating actions have to be taken.

The action that triggered a command and the respective Domain Events has to be re-executed, either by the user or some sort of integration event redelivery, after your retry policies failed.

Source: Architecture-for-Containerized-NET-Applications

Upvotes: 2

Related Questions