I have a question regarding starting a process and waiting for its results.
I’ve implemented multiple workflows and successfully orchestrated them using Camunda.
My current approach involves starting a process and synchronously waiting for the result.
However, I’ve noticed that if the process execution exceeds around 15 seconds, the request times out and I don’t receive a response.
I understand that it’s possible to increase the gateway timeout, and while this works in local development, I’m unsure whether it’s a good practice in a production environment—especially under load—since some processes may take up to a minute or slightly longer.
Would increasing the timeout be a reasonable approach in production, or is it generally discouraged?
I’m also exploring alternative approaches. One option I’ve considered is using Operate’s API to query process results after initiation. However, I’m not sure whether this API is intended for frequent, application-level polling, or if it’s primarily designed for administrative and monitoring purposes.
I’d really appreciate any guidance or best practices on how to handle this kind of scenario.
In Camunda 8, the pattern of starting a process and synchronously waiting for its result is generally only recommended for short-running processes (typically under ~15 seconds). There are two main reasons for this:
Architecture considerations : Camunda 8 is designed as a fully asynchronous, eventually consistent system. Holding a synchronous HTTP connection open for 60+ seconds (especially under load) introduces fragility and goes against the platform’s design principles.
Infrastructure limitations: even if you increase your client-side timeout, you may still run into timeouts at other levels (reverse proxies, load balancers, Kubernetes ingress controllers, etc.). All of these components have their own timeout configurations, which makes this approach difficult to maintain and unreliable in production.
Instead of waiting synchronously, it is generally better to move to an asynchronous pattern. Here are three common approaches:
Callback from the process (recommended)
Start the process without waiting for the result, and at the end of the workflow: Add a service task**,** that call your application via a webhook or message queue. This way, your application is notified when the process completes.
This approach is a well-established and simple pattern, and usually the best choice for most use cases.
Using execution listeners
Similar idea, but using a different mechanism: Start the process asynchronously, then add an execution listener (for example on an endEvent), then notify your application (via webhook or message queue) from the listener (implemented as a job worker).
This approach keeps your BPMN model cleaner in some cases and externalizes the notification logic.
Using a custom exporter
Camunda 8 provides a built-in exporter, but you can also implement a custom exporter to capture process events. In this approach: Start the process asynchronously, then export events (e.g., process completion) then notify you application using a messaging system.
This is more suitable for advanced or specific needs (e.g., centralized event streaming, analytics, integration with external platforms).