OverviewHoney bees have a highly efficient, resilient social structure. If we take a look at how colonies operate with and without a Queen, we can see how mirroring this behavior with servers results in a highly resilient network with aspects of P2P (resiliency) and a more common, centralized setup (efficiency, speed and control).
A quick intro to how honey bee colonies workIf a colony has no Queen, it will most likely fail or, at best, operate inefficiently and without direction. The Queen dictates big decisions, like when the colony will split due to overcrowding and is the only one that produces females. If a Queen dies, or it's time to spit the hive, the female workers will feed royal jelly to random female eggs, converting them into queen eggs. As the Queens hatch, they will either fill the void of the missing Queen, or they will emigrate with a portion of the workers.
Why bee colonies are so fascinating is that the workers will communicate with each other, sharing information to better the colony, but they will prioritize the Queen over their sisters. They are a hybrid of P2P and parent-children networks.
Initial creation and discovery
When a worker node first boots up, it broadcasts out, looking for other nodes and simultaneously accepting connections. Similar to a traditional P2P network, this initial state is slow to connect and to adapt to changes in the network. For instance, if an upgrade was seeded to this network, each node would only be able to update itself if its immediate neighbors also had the update.
It is resilient to damage, since individual workers can die, but it is slow to adopt changes or send information through the network.
Queen is created
Workers nominate a Queen through consensus. Once a worker is converted to Queen, it's primary role is routing communication and destroying compromised workers.
Queen assumes control of routing
All workers, upon sensing a nearby Queen, will attempt to communicate solely through her in an effort to streamline communication.
Queen breeds, splits network
If a Queen becomes overwhelmed with routing, it will breed and designate a worker as a new Queen, spreading the workload. This maintains the benefits of the parent-child optimization, but still maintains some resiliency.
Queen forcibly removed
I'm currently building out a skeleton prototype in Go to see if these concepts work when implemented correctly. I'll be doing a follow up post shortly with results.