The outbox pattern ensures that some actions are going to happen if and only if some other set of actions succeeds first. The most common implementation is a transactional outbox. Here, actions, expressed as data, are stored in a database. When the first set of actions succeeds and transaction is committed, records in the outbox table, become available to any processing reader and can be executed. Another form is to store those actions (having them as data is convenient but delegates are also an option here) in memory and run them on some event, like HTTP request or some background job completing. This persistless approach is a tradeoff between the number of moving parts, performance and reliability (if the process stops — outbox contents are lost). Lets see one of the ways how this in-memory approach can be implemented. Implementation will take place in a legacy ASP.NET application with HTTP modules and all that jazz. It is necessary to publish certain messages to a queue and consume those messages. Here is where the outbox pattern will be applied to make sure that false messages (if a request fails after publishing) do not happen and that any other changes made in the request are already available to query once the consumer is executed. MassTransit (IPublishEndpoint interface will be visible in samples) is used to make work with queues as pleasant as it gets. In memory approach is good enough for all this, however, the publishing of messages will still be tied to NHibernates session (controlled by SessionScope).
