View Source ProcessHub.Strategy.PartitionTolerance.MajorityQuorum (ProcessHub v0.4.1-beta)

The majority quorum strategy provides automatic partition tolerance that adapts to cluster size.

This strategy is ideal for clusters that:

  • Start with a single node (development or initial deployment)
  • Scale up over time
  • Need proper split-brain protection once established
  • Want to avoid manual quorum configuration

How It Works

The majority quorum strategy tracks the maximum cluster size ever seen and requires a majority of those nodes to be present for the cluster to operate.

The quorum is calculated as: floor(max_cluster_size / 2) + 1

Example Progression

1 node   quorum = 1 (can operate)
2 nodes  quorum = 2 (both needed)
3 nodes  quorum = 2 (majority)
5 nodes  quorum = 3 (majority)

Split-Brain Protection

If a 5-node cluster splits into partitions of 3 and 2 nodes:

  • The partition with 3 nodes maintains quorum and continues operating
  • The partition with 2 nodes loses quorum and enters partition mode (distributed supervisor and all children are terminated)

Configuration

partition_tolerance_strategy: %ProcessHub.Strategy.PartitionTolerance.MajorityQuorum{
  initial_cluster_size: 1,  # Default: 1 (works with single node)
  track_max_size: true      # Default: true (adapts to cluster growth)
}

Intentional Downsizing

Scaling Down Requires Manual Intervention

MajorityQuorum does not automatically handle cluster scale-down. The strategy remembers the maximum cluster size to protect against split-brain scenarios. If you scale down nodes (e.g., from 5 to 3 nodes), the cluster will still require a majority of the original 5 nodes (i.e., 3 nodes) to operate.

For automatic adaptation to gradual scale-down, consider using ProcessHub.Strategy.PartitionTolerance.DynamicQuorum instead.

If you intentionally downsize your cluster (e.g., from 5 nodes to 3 nodes), you'll need to reset the expected cluster size, otherwise the cluster will require 3 nodes (majority of 5) to operate.

You can reset the expected cluster size using:

ProcessHub.Strategy.PartitionTolerance.MajorityQuorum.reset_cluster_size(:my_hub, 3)

Options

  • initial_cluster_size - The initial expected cluster size. Default: 1. Used as the starting point for quorum calculation until a larger cluster is seen.

  • track_max_size - Whether to automatically track and remember the maximum cluster size ever seen. Default: true. If set to false, the quorum will always be calculated based on initial_cluster_size.

Summary

Types

t()

Majority quorum strategy configuration.

Functions

Resets the expected cluster size for a ProcessHub instance.

Types

@type t() :: %ProcessHub.Strategy.PartitionTolerance.MajorityQuorum{
  initial_cluster_size: pos_integer(),
  track_max_size: boolean()
}

Majority quorum strategy configuration.

  • initial_cluster_size - The initial expected cluster size. Used as the starting point for quorum calculation. Default: 1 (supports single-node startup).
  • track_max_size - Whether to automatically track and remember the maximum cluster size ever seen. Default: true.

Functions

Link to this function

reset_cluster_size(hub_id, new_size)

View Source
@spec reset_cluster_size(atom(), pos_integer()) :: :ok | {:error, term()}

Resets the expected cluster size for a ProcessHub instance.

This is useful when intentionally downsizing your cluster. Without resetting, the cluster will continue to require a majority of the maximum size ever seen.

Parameters

  • hub_id - The ProcessHub instance ID
  • new_size - The new expected cluster size

Example

# After downsizing from 5 nodes to 3 nodes
ProcessHub.Strategy.PartitionTolerance.MajorityQuorum.reset_cluster_size(:my_hub, 3)

This will update the maximum seen cluster size to 3, so the cluster will now require a majority of 3 (i.e., 2 nodes) instead of a majority of 5 (i.e., 3 nodes).