Internal Commands

[AurelianTimu]

Hi,

First of all, thank you for your work with this repository.

I can't properly understand the purpose of the Internal Commands.
Why should we use Internal Commands?
There seems to be an overhead by using them - i'm referring to the fact that an additional worker is needed to pool them from the database and after that dispatch them to the handlers. What are the benefits?

Thanks.

[AndreiGanichev]

Hi,
the main benifit is reliability. ProcessInternalCommandsCommandHandler configures retry policy to handle exceptions and even if a command wasn't finally processed the command and the error won't be lost. Later you can analize errors and can easily try to handle the command again.

The other point is ability to control the rate at which messages are processed. Application now are not to process a message as soon as it is delivered but application is able to choose the pace of processing.

[kgrzybek]

I agree with @AndreiGanichev .

Background processing with persistence (durability) gives you reliability.

I observed that without such a mechanism developers choose strong consistency instead of eventual consistency because without durable jobs there is a risk that the system will lose consistency at all. Strong consistency means bigger transactions and performance problems.

So, finally, it is a matter of architectural decision:

• you want more reliability - you need to use/implement some background processing, keep its state and it will use more threads
• you accept that sometimes your system will be inconsistent (unreliable) - for example, you will save the Order, and email notification will fail.

[i-vukman]

@kgrzybek The confusing part for me here is that there are already outbox messages being processed by notification handlers.
Outbox messages are already durable and are being processed in background.

What do we gain from scheduling internal command from notification handler?

In some cases, the reasoning to use internal command is obvious, such as in ExpireSubscriptionsCommandHandler where each expired subscription gets its own ExpireSubscriptionCommand enqueued.

But in some cases, notification handler that is being executed based on outbox message just enqueues a command. Couldn't that command be implemented in handler itself then?

[AurelianTimu]

Thank you guys for the explanations. I appreciate it.