Blockchain Patterns, Mechanisms, Models, Metrics > Scalability and Reliability Patterns > Auto-Scaling Nodes
Auto-Scaling Nodes (Erl, Naserpour)
How can a blockchain network be reliably scaled to consistently provide the necessary quantity of nodes to fulfill consensus processing requirements?
A given consensus algorithm may require that a minimum quantity of nodes be active and available as a pre-condition to carrying out the consensus process.
Active nodes in a blockchain network are constantly monitored. When the quantity of nodes falls below pre-defined thresholds, new nodes are automatically generated to maintain the consensus processing requirements.
The minimum number of full and/or partial nodes is defined and checked by the consensus processor mechanism. The node monitor mechanism is used to monitor active nodes and to notify the automated node deployer when new nodes are required.
Consensus Processor, Node Monitor, Automated Node Deployer
The consensus algorithm being used for a blockchain application requires that there be a minimum of 24 full nodes active to compete for the eligibility to carry out core consensus tasks and to also carry out these tasks. Additionally, the consensus algorithm requires at least 36 more nodes to be available to participate in a voting process that is part of the consensus algorithm logic. To minimize power consumption requirements, these additional 36 nodes can be partial nodes. The node monitor is programmed with these requirements and monitors the blockchain network accordingly. In the depicted scenario, the node monitor notices that the quantities of full and partial nodes that have signed onto the network are insufficient. The consensus processor is made aware of this and cannot proceed to carry out a consensus process.