@faroni, Yeah, your concern is very valid—there is a fundamental difference in how job activation works between Camunda 7 and Camunda 8 (Zeebe). Let’s unpack it and look at what the implications are for performance and how you can mitigate them.
Camunda 7 vs. Camunda 8 - Job Fetching
Camunda 7:
The fetchAndLock REST API allows fetching multiple topics in a single request.
Very REST-friendly, good for high topic count, simple scaling.
Camunda 8 (Zeebe):
Each worker is tied to a single job type.
You can only activate jobs of one type at a time via the ActivateJobs gRPC or REST Gateway.
This model is designed to scale horizontally using gRPC rather than scaling via API call density. But it can seem more burdensome if you’re used to the batch-like efficiency of Camunda 7.
What Are the Real Limits?
Zeebe Gateway (REST/gRPC):
No hard limits like rate throttling on the number of ActivateJobs requests.
But:
Each request hits the Gateway.
The Gateway forwards it to a partition leader.
If requests are too frequent, and especially if no jobs are available, it can create pressure and increase activation delay.
In your case (10-100 calls/sec):
If most calls result in active jobs being found, you’re fine.
If many result in no jobs available, you’re creating load with no benefit — this is what the article you mentioned warns about.
Strategies for Efficient Job Consumption
Use Long Polling (requestTimeout)
This is key: set a higher requestTimeout (e.g., 30s).
The Gateway holds the request open until a job is available or timeout is reached.
Reduces “empty” polling and system load dramatically.
Use gRPC Instead of REST if Possible
REST is just a wrapper around gRPC and adds a bit of overhead.
If your workers are in Java or Node, prefer the native gRPC clients.
Use Job Worker Libraries
Camunda-maintained clients (like Java client) manage polling, backpressure, and exponential backoff for you.
They’re far more efficient than DIY polling logic.
Batch Job Activation
Set maxJobsToActivate > 1 to get more jobs per call.
If a worker can process in parallel or queue jobs, this helps.
Distribute Job Types Across Workers
Instead of one worker per job type, you can register multiple types on a single process or thread pool.
This requires managing your own pooling logic, but avoids the 1:1 job type to worker constraint.
Use Fewer Job Types (if you can)
If your 100+ types can be grouped logically, consider using metadata/variables to differentiate within a smaller number of types.
Recap: What Should You Do Now?
• Use long polling (requestTimeout: 30000) and batch activation (maxJobsToActivate: 10+).
• Avoid frequent empty polling, especially in idle periods.
• Consider gRPC clients or Camunda’s Java client instead of pure REST.
• Monitor Gateway CPU and request rates via Prometheus to detect pressure.