Service Task as Asynchronous

How many Asynchronous after/before we can or should put on single flow(Order journey)?

Currently we are having total 10 business processes to fulfil the order and 10 external system calls in them.

We had put Asynchronous after for all 10 service tasks and observed that there were Inserts- 37 Deletes-34 Updates-24. So ~ 100 DB interactions.

Due to these many db interactions we feel there will be performance impact.

There’s no one-size fits all answer for this, because it depends on what you are optimising for. If you’re looking to have as few as possible DB interactions for performance reasons, you might choose to not mark tasks as async before. However, if one fails, the rollback that occurs will take you back to the last known correct state and re-attempt everything from there, which may also not be what you want. In some cases, tasks are non-idempotent, because they have side effects that you don’t want to trigger twice.

In systems where consistency and transaction scope are paramount, I usually apply: make all service tasks (and send events) async before. If they are also non-idempotent, additionally async after. All user tasks async after so the user is not presented with failures down the line.

Camunda have some best practices on this, here: Camunda Best Practices - Dealing With Problems and Exceptions

1 Like