By spreading the workload among multiple servers, you avoid having some servers idle while others have tasks queuing for execution. Distribution also allows for parallel processing.
When a particular engine is brought up in distributed mode, it inserts itself into the ring, and the other engines in the ring are informed of the insertion.
Conversely, all engines in the ring are informed if a particular engine drops out of the ring. When an engine drops out within a distributed ring, the other engines automatically take over its work. When it re-enters the ring, it will continue to accept process instances. The engine uses an internal algorithm to assign process instances to analysis threads, and once an instance has been assigned to a thread, that thread does all of its processing.
When multiple engines are running in a distributed ring, the algorithm takes into account all the analysis threads of all the running engines. In essence, all of the analysis threads across all the engines function as though they were all running in the same engine. When an engine drops from the ring, the process instances being handled by its analysis threads are picked up by existing engines and reassigned to one of their analysis threads.
Transaction boundaries exist in all the threads in all the engines. This means the existing analysis threads can access the database and get the last state of each process that was being handled by the missing engine and the route state and content of each event. The restart procedure reassigns the work: the existing engines grab the current state of all process instances that were running in the missing engine, assigns them to existing analysis threads, grabs all the routes for those processes that are not complete, recreates the events, and then sends them off to the newly reconstituted process instances. If the missing engine rejoins the ring, any of its process instances that have not completed are returned to its analysis threads.