Hi, thanks for your interest in Serf!
Although Serf could certainly be used in a configuration with only two nodes, most of the benefits of its gossip-style membership are only realized in larger deployments.
If the nodes are relatively static (i.e. have fixed IP addresses) then Serf wouldn't provide much value over a more traditional heartbeat-based solution with only two members.
That said, if you were planning to make use of Serf's other features, such as by using its event-handler system to automate failover, or would just prefer to avoid implementing your own heartbeat system, the Serf binary could be useful.
You also mentioned future interconnectivity with other clusters over an unreliable network. We've certainly seen Serf (and the underlying memberlist library) used to implement membership over higher latency links - this is how Consul's WAN federation works, for example.
For this, you'd need to tune the various parameters (e.g. timeouts, probe interval) to find the right balance between timely failure detection and handling transient connection issues. We've only really deployed Serf in situations where the network is basically reliable with occasional hiccups, rather than systems where members are frequently offline for extended periods. Your mileage may vary!
As you've mentioned that you're implementing an active/passive system, I wonder if Consul might be a better fit? It has primitives for implementing leader election, if that's useful for you: https://developer.hashicorp.com/consul/tutorials/developer-configuration/application-leader-elections
Hope that's helpful!
Dan Upton (he/him)
Senior Engineer, Consul Core Platform