Unclear Split Brain Resolver strategy selection in Akka Cluster

Short answer

For a typical three-to-five node Akka Cluster, keep-majority is the best default: it guarantees that at most one side of any partition can survive (so singletons cannot diverge), and it keeps the cluster available as long as a majority of nodes remain connected. Use lease-majority only if you have a reliable lease implementation and need to survive even splits; avoid keep-oldest if your oldest node is subject to rolling restarts.

Why keep-majority wins here

The safety property you care about — no two cluster singletons running on opposite sides of a partition — comes from the majority rule: two disjoint groups can never both hold a majority of the same node set. With 3–5 nodes:

• A partition that isolates one node leaves a majority of 2–4 nodes running; only the lone node is downed.
• A clean even split (2 vs 2 in a four-node cluster) downs both sides, which is safe but unavailable — the main gap lease-majority addresses.
• Compared with down-all, which stops everything whenever quorum is lost, keep-majority gives you the same correctness with far less downtime.

static-quorum can be equally safe if you set the quorum to ⌊N/2⌋+1, but it does not adapt when you add or remove nodes — you must reconfigure it, and a misconfigured quorum can either down the cluster unnecessarily or, worse, allow divergent decisions. For a cluster whose size may drift, keep-majority removes that footgun.

Keep-oldest and rolling restarts

Keep-oldest keeps the side containing the node with the earliest membership (the "oldest" node) and downs the rest. The trap for your scenario: if the oldest node is on the minority side of a partition — or is briefly down during a rolling restart — the strategy can down the majority side, because the decision criterion is node age, not partition size. In practice this means a routine restart of your longest-running node can take the whole cluster down. Exact behavior around a temporarily unreachable oldest node (immediate down vs. waiting for a decision timeout) has varied across Akka versions, so verify against the documentation for your specific release (2.6.x vs 2.8.x differ in SBR details) before relying on it. Unless you can pin the oldest node to a host that never restarts, keep-oldest is a poor fit for clusters with frequent rolling deploys.

Is lease-majority worth the complexity?

Lease-majority behaves like keep-majority but uses an external lease (via Akka's Lease API — e.g., a Kubernetes lease or another consensus-backed implementation) to break ties, so one side of an even split can survive. That is a genuine availability gain, but you pay for it with:

• An extra infrastructure dependency whose outage or misconfiguration can cause wrong downing decisions or prevent any majority from forming.
• Additional tuning of lease heartbeat and timeout settings that must be consistent with your failure-detector settings.

For a 3–5 node cluster where even splits are rare and brief unavailability during them is acceptable, the added operational burden usually is not justified. It becomes attractive in larger clusters or where even splits are structurally likely (e.g., two racks of equal size).

Verification before committing

1. Confirm SBR availability and defaults for your Akka version in the official docs; SBR is built into Akka Cluster in recent 2.6+ releases.
2. Stand up a three-node test cluster with keep-majority, partition one node (e.g., with iptables or a network namespace), and confirm the two-node side survives and the singleton stays there.
3. If you are tempted by keep-oldest, stop the oldest node briefly and watch the SBR log lines to see whether the rest of the cluster is downed.
4. If evaluating lease-majority, create an even split, confirm the lease-holding side survives, then kill the lease service and confirm the cluster degrades to a safe state rather than a split-brain.

Note: exact strategy names, defaults, and keep-oldest edge-case behavior are version-sensitive — treat the above as well-established guidance and confirm specifics against the docs for your Akka release.