Camunda 8 | State storage & Event storage

[saiprasad.krishnamur]

Hi there,
We use Camunda 7 in my company and currently looking to evaluate Camunda 8. We have huge workloads as our systems are flooded with heavy traffic every second. I just started reading the docs of Camunda 8 and understand it’s built based on cloud native principles (event-driven, distributed, horizontal partition enabled etc) all good stuff.

Wanted to understand the following:

What is the event bus that Camunda 8 uses for it to exchange between various workers/members? Is that a built-in mechanism or an external broker like Kafka?

I understand that the workflow engine still needs to store the state in a persistent store (some database) right? This is for to know what task has been finished (for tracking) and where we are in the workflow. And also for merging the flows from multiple branches. The process should know when the merge is fully considered to be complete.
If this is the case, what database is used and how does Camunda 8 ensure the data consistency in case of multiple instances to avoid missing a state update in case of a network lag or glitch etc.?

[StephanHaarmann]

Hi @saiprasad.krishnamur,

1. The Zeebe-Brokers implement the RAFT algorithm. The leader distributes events to its followers using this protocol without an external broker.
2. The workers retrieve work from the engine using the gRPC api.
3. The engine state is persisted. Therefore, a high-performance key value store (RocksDB) is used, which cannot be accessed outside the engine. Reads @korthout response in the following thread to learn more about scalability and fault tolerance:

Does Zeebe store its state in RocksDB or any database?

Hi @sherry-ummen, Zeebe does not use a centralized, external or shared database. @deepthi gave a great talk about scaling workflow engines which discusses the problem of such databases in the first 2 minutes and then goes on to explain how Zeebe solves the problems of scaling and fault tolerance Scaling a distributed workflow engine (CamundaCon 2019) - YouTube. You can also read more about our technical concepts here. Lastly, to more directly answer your question about RocksDB. Zeebe does us…

[saiprasad.krishnamur]

Thanks for this.
Just curious, is there a reason for Zeebe to not to go with a totally “event-driven” approach? ie Workflow engine dispatches a task to the worker via a topic and worker reacts to the event and pushes back and signals back in the topic (as opposed to the worker pulling the tasks via a gRPC pull mechanism)? I’m sure there must be great design decisions behind it. I just want to understand the reasoning out of curiosity.