Scalability of HTTP Webhook Connector vs Job Worker for High-TPS Use Cases in Camunda 8

Camunda 8 Topics Discussion & Questions
1

Hello All,

We are currently evaluating the Camunda 8 HTTP Webhook Connector for processing inbound external calls and are experiencing challenges in scaling it beyond 20 transactions per second (TPS).

Use Case:

  • External systems invoke Camunda via the HTTP Webhook Inbound Connector.
  • We expect traffic volumes to scale beyond 100+ TPS in peak scenarios.
  • We’ve observed bottlenecks or throughput degradation around the 20 TPS mark despite optimized deployment and container resources.

Questions:

  1. Is the HTTP Webhook Connector recommended for high-throughput or high-TPS scenarios in production?
  2. How does its performance and scalability compare to a custom Zeebe Job Worker built using Java or other client libraries?
  3. Are there any configuration optimizations or best practices specific to scaling the webhook connector?
  4. Would using a Job Worker pattern be more appropriate for guaranteed delivery and elastic scaling in high-volume scenarios?

Any guidance or recommended architectural patterns from the Camunda team or community would be greatly appreciated.

Thank you!
-Hariharan

2

Hi @Hariharan_Eswaran, welcome to the forums! Can you share a bit more about your environment and what testing you’ve done?

  • How do you have Camunda deployed?
  • Can you share your config? (docker-compose.yaml, Helm values, etc. - with secrets redacted of course)
  • How do you have the connector runtime deployed and configured for scaling?
  • Do you have any logs or metrics demonstrating the degradation?
  • Is each webhook request starting a new PI, interacting with a running PI, or a mix?

Connectors - including the inbound connectors - are essentially fancy job workers, so I don’t think you’d see any significant improvement using a job worker. However, assuming these requests all start a process instance, you might see an improvement by skipping the webhook connector and calling the Camunda API directly. But there are a lot of variables and it depends; answering the questions above will help narrow those variables.