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?

[ChrisPaulP]

Hi @i-vukman what conclusion did you come to on this? I agree with you. Is this not a case of over engineering?

[i-vukman]

Is this not a case of over engineering

Not necessarily.

Command handlers are decorated so that event dispatching and UoW commit cross cutting concerns are implemented out of the box.

Even if notification handler did handle the logic that is delegated to command handler, it would still need to execute the command and not implement the logic inside the notification handler directly in order to benefit from those decorators.

Further, notification handlers seem to carry light weight tasks that are not likely to fail, such as publishing event to event bus or scheduling internal commands.

Internal command processing handles failures more robustly, with retry logic being in place.

All of this makes sense since we don't want to introduce congestion at notification handler level since it also delivers events to other modules, each of which processes events independently.

[AurelianTimu]

Thank you guys for the explanations. I appreciate it.