I believe there remains some misunderstanding here. Camunda is a process orchestration platform, powered by a distributed, asynchronous workflow engine (Zeebe). It is not a routing engine.
Camunda is designed and optimized for complex and high-volume process automations across multiple internal and external services. To use @MagzhanUnited’s process as an example, that process is far more efficient as a switch statement in your own application. (This is an area where our documentation could definitely use some improvement; I’ve shared these questions with the team, and we’re going to come up with a plan to improve it - if you have further feedback on this aspect of the documentation, please message me, I’d love to hear it!)
I think this blog post by one of our co-founders, Bernd Rücker, helps explain where process orchestration is beneficial and where it is not the right solution:
Camunda probably isn’t the right fit if you want to click a button and display a form or two to your user. However, imagine a loan application at a bank: once the application form is submitted, a larger series of tasks and decisions is initiated. You must validate the application, validate the applicant’s identity, pull their credit report, perform a risk assessment, and, depending on the loan type, many other steps, before the funds are disbursed to the account. Automating the loan application process end to end is a great use of Camunda and process orchestration.
Camunda enables creating and managing these processes, and what the individual tasks in each process do, with a no/low-code approach, a pro-code approach, or a mix. However, Camunda is not a drop-in no-code solution for your backend.
Now let’s talk about that “delay” and some solutions …
Depending on the size of your cluster in SaaS (or the resources you’ve allocated to your Self-Managed deployment), the speed at which a process instance starts is somewhat variable. If the first task in your process is a form, a delay of a few seconds from sending the request to start the process to the time that form is available in Tasklist or via the API is somewhat expected. Camunda is capable of running millions of process instances at a single time, so there are optimizations that can be done to help minimize that time delay. But remember that Zeebe is an asychronous and event-driven engine, not a synchronous and transactional one.
If a user interaction requiring a form is the start of your process, you can skip the process instantiation step entirely and start a process directly with a form.
If you have a more complex process that requires forms or human interaction in the middle (and you aren’t using Tasklist), I would consider using the “push” method I described in my previous reply: instead of your application polling the process to watch for these events, have the process tell your application when those events happen.
A similar “push” method can be used for events beyond user tasks; for instance, if your application needs to know when a process has ended, you can include a final service task right before the end event that notifies your application. (Generally speaking, it is a best practice to explicitly model as much of this as possible.)
Phew, that was a lot of writing!
Thanks for reading through this long reply! I felt it needed a much more detailed explanation, as we have received this same question from several users this week. Hopefully this helped clarify things; if not, please let me know what other questions you have. As mentioned earlier, this is something we need to improve in our documentation and I’ll be working with the team to make those improvements. If you have any specific feedback or thoughts on the documentation, please send me a message, I would love to hear it