I am currently assessing multiple possible use cases to be handled by the engine.
A concern that I have is about the Zeebe Job Type metadata that is used to
subscribe workers to tasks.
My concern is the following:
Assuming you have multiple services, and you want to enable the possibility to create
different kind of workflows inside those services (basically a service owns a workflow).
You use Zeebe as central component.
I see a strong possibility of having, not by intent, the same zeebe job type, placed in different unrelated
workflows, from different services.
Therefore workers can from one service can handle jobs from the workflow that is not linked with that
service. Expecting maybe some particular variables, and even do some specific handling that only
works for the workflow that is owned by that particular service.
I know the Zeebe purpose is to act as a broker. But this just seems like something tricky. If you work
with multiple people, working in different services, I see that a possible scenario.
So I am curious what can you do to protect from something like this. My thoughts are:
Enforce somehow the uniqueness of the zeebe job type, between different workflows ? Is
something like this possible ?
In the worker code from a service, filter the job metadata to be linked with the process id that
the service owns. But the issue I see here, is cause even if you ignore the other task, from a
different workflow it will still delay the execution of the other workflow. Cause it will take a time
till the ignored task is rescheduled.
Promote a design mindset on all the people involved in the project to take into account this
behavior, but again this still is prone to unwanted effects
Based on the architecture I have in mind for the system, I think the way to have service owned workflows that do not span other services, seems a good approach in my situation.
But I have this concern in mind.
I would appreciate any advice on this, thank you !