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 use a database and you’re right, that’s RocksDB. Each Zeebe broker is in charge of 1 or multiple partitions. Per partition it keeps track of a log of records and it keeps a view of the current state. As it processes records on the log it updates the view (or state) in RocksDB. If the broker goes down for what ever reason, another broker can take over the work (as long as the replicationCount is > 1), because the log was replicated. That broker just has to replay the events on the log to produce the same view of the state in its own RocksDB and can then start processing as leader of that partition. In reality, there’s a bit more to it, like creating snapshots to compact the log, replay on followers to speed up transitioning to leader role, etc, but this is the main idea about the log and the local state.
Hope that makes sense.