Hey, mates 
Currently my team is working on replatforming some mid large microservices-based application to use Camunda as its core for all our complex business flows. Mostly - for better understanding and monitoring of those distributed processes by departments. Having process documentation and execution at the same place is great.
For some big, almost fully automated process, the question is what are the sane constraints/boundaries of splitting it into the smallest possible (atomized) tasks in the context of using Zeebe?
Into more atomized tasks we split its model - more control and visibility we have over the process, however it makes sense only to some limit. Also we need to consider that more involve Zeebe between tasks - worse it will impact latency and perfomance. Technically, we could have just few heavy service tasks but to split heavy tasks is exactly half of the actual goal.
Imagine a loan application at a bank: once the application form is submitted, a larger series of tasks and decisions is initiated. It validates the loan application, validates the applicant’s identity, pulls a credit report, performs a risk assessment, and, depending on the loan type, many other steps, before the funds are disbursed to the account.
Is there as any good rule of thumb we can follow:
E.g., split into tasks by some kinda “1 transaction - 1 service task” rule, then combine these task in some subprocess? Or bare with the thing that a lot of processing will happen implicit in process model, encapsulated in one service task but it’s fine as long as concerns rather an engineering team than business/stakeholders?
Thanks in advance
Alex