Rqlite 6.0: the evolution of a distributed database design
6.0 multiplexes multiple logical connections between rqlite nodes using the existing Raft inter-node TCP connection. The first thing to understand is that each rqlite node exposes two network interfaces - first, a Raft network address managed by the Hashicorp Raft system, and second, a HTTP API which clients use to query the SQLite database. While each node knows the Raft network address of every other node thanks to the Hashicorp Raft implementation, each rqlite node must also learn the HTTP URL of the Leader, so it can inform client code where to redirect queries. Since the Leader can change and even be completely replaced, each rqlite node must have up-to-date information regarding the Leader HTTP URL at all times. Rqlite nodes returned the Raft network address of the Leader to the client, if the requested operation could only be served by the Leader. This forced the client to check all other cluster nodes, to see which one had the relevant Raft address, and then redirect the query itself to that node's HTTP API URL. While this meant the rqlite code was much simpler than later versions, this approach only worked if the client knew about every node in the rqlite cluster, or always knew which node was Leader. Thanks to the Raft consensus system every node always knows every other node's Raft network address so, in theory, each node could learn every other node's HTTP API URL via this mapping.