The replication strategy allows for multiple instances of a process to be started across the cluster. The number of instances is determined by the replication_factor option.

The replication strategy also comes with a replication_model option, which determines which instances of the process are active and which are passive. Imagine a scenario where you have a process that is responsible for handling streams of data. You may want to have multiple instances of this process running across the cluster, but only one of them should be active at any given time and insert data into the database. The passive instances of the process should be ready to take over if the active instance fails.

Replication strategy selects the master/active node based on the child_id and child_nodes arguments. The child_id is converted to a charlist and summed up. The sum is then used to calculate the index of the master node in the child_nodes list. This ensures that the same master node is selected for the same child_id and child_nodes arguments.

This strategy also allows replication on all nodes in the cluster. This is done by setting the replication_factor option to :cluster_size.

ProcessHub can notify the process when it is active or passive by sending a :redundancy_signal.

Using the :redundancy_signal option

When using the :redundancy_signal option, make sure that the processes are handling the message {:process_hub, :redundancy_signal, mode}, where the mode variable is either :active or :passive.

Example GenServer process handling the :redundancy_signal:

def handle_info({:process_hub, :redundancy_signal, mode}, state) do
  # Update the state with the new mode and do something differently.
  {:noreply, Map.put(state, :replication_mode, mode)}
end