How does SolrCloud handle a split-brain or network partition scenario?

Split-brain - two nodes both believing they're the legitimate leader and accepting conflicting writes - is exactly what SolrCloud's ZooKeeper-based coordination is designed to prevent, by relying on ZooKeeper's own quorum guarantee rather than inventing a separate consensus mechanism.

ZooKeeper itself only operates when a majority (quorum) of its ensemble nodes can communicate - a 5-node ensemble tolerates 2 failures, a 3-node ensemble tolerates 1. During a network partition:

• The side of the partition with a ZooKeeper quorum continues to function normally, including electing leaders for any shard replicas on that side.
• The side without quorum cannot get its ZooKeeper client sessions renewed, and Solr nodes on that side lose their ephemeral leader/live-node registrations. They effectively stop accepting writes as leaders rather than risk conflicting with the other side.

This means SolrCloud favors consistency over availability for the minority side of a partition (a CP-leaning choice): rather than allowing two leaders to diverge, the minority side degrades to read-only or unavailable for affected shards until connectivity to a ZooKeeper quorum is restored. The practical implication for operators is that ZooKeeper ensembles should always run with an odd number of nodes spread across failure domains, since ZooKeeper's own availability is the ceiling on SolrCloud's write availability during a partition.