ಯಾರೂ ಜವಾಬ್ದಾರರಲ್ಲದಿದ್ದಾಗ ನೀವು ದೊಡ್ಡ ಯೋಜನೆಯನ್ನು ರೂಪಿಸಿದರೆ ಏನಾಗುತ್ತದೆ? ಹೆಚ್ಚಿನ ಸಾಫ್ಟ್ವೇರ್ ಸ್ಟ್ಯಾಕ್ಗಳು (software stacks) ಏಕೈಕ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ (orchestrator) ಅನ್ನು ಹೊಂದಿರುತ್ತವೆ ಎಂದು ಭಾವಿಸುತ್ತವೆ. ಒಂದು ಪ್ರಕ್ರಿಯೆಯು ಸ್ಥಿತಿಯನ್ನು (state) ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಕೆಲಸಗಳನ್ನು ಕ್ಯೂ (queue) ಮಾಡುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯಗಳನ್ನು ಹಂಚಿಕೆ ಮಾಡುತ್ತದೆ. ಆ ಸಂಯೋಜಕರು (coordinator) ಮರುಪ್ರಾರಂಭಗೊಂಡರೆ, ಇಡೀ ಕಾರ್ಯಪ್ರವಾಹವು (workflow) ಅಸ್ತವ್ಯಸ್ತವಾಗುತ್ತದೆ. ಹೊಸ ಯೋಜನೆಯು ಆ ಕಲ್ಪನೆಯನ್ನೇ ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸುತ್ತದೆ. ಯಾವುದೇ ಒಂದು ನೋಡ್ (node) ಸಂಪೂರ್ಣ ಯೋಜನೆಯನ್ನು ಹೊಂದಿರದೆ, "ಜಪಾನ್ಗೆ ಎರಡು ವಾರಗಳ ಪ್ರವಾಸವನ್ನು ಯೋಜಿಸಿ" ಎಂಬ ಗುರಿಯನ್ನು AI ಏಜೆಂಟ್ಗಳ ಸಮೂಹವು ಹೇಗೆ ಸಂಪೂರ್ಣ ಕಾರ್ಯ ಮರದಾಗಿ (task tree) ವಿಭಜಿಸಬಹುದು ಎಂಬುದನ್ನು ಇದು ತೋರಿಸುತ್ತದೆ.
ನಾಯಕತ್ವವಿಲ್ಲದ ವ್ಯವಸ್ಥೆಯನ್ನು (Leaderless System) ಏಕೆ ನಿರ್ಮಿಸಬೇಕು?
ಕೇಂದ್ರೀಕೃತ ಯೋಜಕರು (Centralized planners) ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭ. ನೀವು ಸರ್ವರ್ಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತೀರಿ, ಅದು ಕೆಲಸವನ್ನು ವಿಭಜಿಸುತ್ತದೆ ಮತ್ತು ಕೆಲಸಗಾರರು ವರದಿ ಮಾಡುತ್ತಾರೆ. ಸಮಸ್ಯೆ ಏನೆಂದರೆ, ಸರ್ವರ್ ಒಂದು ಬೌದ್ಧಿಕ ಮತ್ತು ಭೌತಿಕ ಅಡಚಣೆಯಾಗಿ (bottleneck) ಪರಿಣಮಿಸುತ್ತದೆ. ಅದು ಸತ್ಯವನ್ನು ತನ್ನ ವಶದಲ್ಲಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ.
ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ (distributed setup), ಸತ್ಯವು ನೆಟ್ವರ್ಕ್ನ 'ಗಾಸಿಪ್' (gossip) ಮೂಲಕ ಒಮ್ಮತಕ್ಕೆ ಬರುವ ಒಂದು ಹಂಚಿಕೆಯ ಚಿತ್ರಣವಾಗಿ ಬದಲಾಗುತ್ತದೆ. ಈ ನಿರ್ದಿಷ್ಟ Python ಅನುಷ್ಠಾನವು (implementation) ಎರಡು ವಿಭಿನ್ನ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಜೋಡಿಸುತ್ತದೆ. ಮೊದಲನೆಯದು ಪುನರಾವರ್ತಿತ ಪರಿಷ್ಕರಣಾ ಲೂಪ್ (iterative refinement loop): ಒಂದು ಏಜೆಂಟ್ ಪ್ರಸ್ತಾವನೆಯನ್ನು ಬರೆಯುತ್ತದೆ, ಇನ್ನೊಂದು ಅದಕ್ಕೆ ಅಂಕ ನೀಡುತ್ತದೆ ಮತ್ತು ಮೂರನೆಯದು ಅದನ್ನು ಪರಿಷ್ಕರಿಸುತ್ತದೆ. ಎರಡನೆಯದು libp2p ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಪೀರ್-ಟು-ಪೀರ್ (peer-to-peer) ನೆಟ್ವರ್ಕಿಂಗ್ ಲೇಯರ್ ಆಗಿದ್ದು, ಇದು ಯಾವುದೇ ರಿಜಿಸ್ಟ್ರಿ ಅಥವಾ ಲೋಡ್ ಬಾಲನ್ಸರ್ ಇಲ್ಲದೆ ಏಜೆಂಟ್ಗಳು ಪರಸ್ಪರರನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕಂಡುಕೊಳ್ಳಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಇದರ ಫಲಿತಾಂಶವೆಂದರೆ, ಯಾರೂ ಆರ್ಕೆಸ್ಟ್ರಾ ಕಂಡಕ್ಟರ್ ಆಗಿ ಕೆಲಸ ಮಾಡದೆಯೇ ಪೀರ್ಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುವ, ಪ್ರಸ್ತಾಪಿಸುವ, ಮತ ಚಲಾಯಿಸುವ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಒಂದು ಕ್ಲಸ್ಟರ್ (cluster).
ನಾಲ್ಕು ಪಾತ್ರಗಳು
ವ್ಯವಸ್ಥೆಯು ಪ್ರತಿಯೊಬ್ಬ ಪಾಲ್ಗೊಳ್ಳುವವನಿಗೆ ನಾಲ್ಕು ವ್ಯಕ್ತಿತ್ವಗಳಲ್ಲಿ ಒಂದನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ನಿಮಗೆ ನಾಲ್ಕು ಭೌತಿಕ ಯಂತ್ರಗಳ ಅಗತ್ಯವಿಲ್ಲ. ಅವು ಒಂದೇ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಇರಬಹುದು ಅಥವಾ ಹೋಮ್ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಹರಡಿರಬಹುದು. ಪಾತ್ರಗಳು ಹೀಗಿವೆ:
Decomposer. ಈ ಏಜೆಂಟ್ ಉನ್ನತ ಮಟ್ಟದ ಗುರಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಉಪಗುರಿಗಳಾಗಿ (subgoals) ವಿಭಜಿಸಲು ಪ್ರಸ್ತಾಪಿಸುತ್ತದೆ. ವ್ಯವಸ್ಥೆಯು ಏಕಕಾಲದಲ್ಲಿ ಹಲವಾರು decomposers ಅನ್ನು ನಡೆಸುವುದರಿಂದ, ಒಂದೇ ಜಪಾನ್ ಪ್ರವಾಸಕ್ಕಾಗಿ ನೀವು ಮೂರು ವಿಭಿನ್ನ ವಿಧಾನಗಳನ್ನು ಪಡೆಯಬಹುದು. ಒಂದು ಭೌಗೋಳಿಕವಾಗಿ ಪ್ರಯಾಣವನ್ನು ವಿಂಗಡಿಸಬಹುದು: ಟೋಕಿಯೊ, ಕ್ಯೋಟೊ, ಒಸಾಕಾ. ಇನ್ನೊಂದು ಚಟುವಟಿಕೆಯಿಂದ ವಿಂಗಡಿಸಬಹುದು: ಸಾರಿಗೆ, ವಸತಿ, ಆಹಾರ, ಪ್ರವಾಸಿ ತಾಣಗಳು. ಮೂರನೆಯದು ದಿನಗಳ ಪ್ರಕಾರ ಕ್ರಮಬದ್ಧಗೊಳಿಸಬಹುದು. ನೆಟ್ವರ್ಕ್ ಇವೆಲ್ಲವನ್ನೂ ಪರಿಗಣಿಸುತ್ತದೆ.
Scorer. ಈ ಏಜೆಂಟ್ಗಳು ಸಂಪಾದಕೀಯ ಮಂಡಳಿಯಂತೆ (editorial board) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಅವು ಪ್ರಸ್ತಾಪಿತ ವಿಭಜನೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತವೆ ಮತ್ತು ಅದಕ್ಕೆ ರೇಟಿಂಗ್ ನೀಡುತ್ತವೆ. ಅಂಕವು ಉಪಗುರಿಗಳು ಸಾಕಷ್ಟು ಸ್ಪಷ್ಟವಾಗಿವೆಯೇ, ಒಂದಕ್ಕೊಂದು ಅತಿಕ್ರಮಿಸದವೆಯೇ ಮತ್ತು ಸಾಮೂಹಿಕವಾಗಿ ಪೂರ್ಣವಾಗಿವೆಯೇ ಎಂಬುದನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ. ಮುಖ್ಯವಾಗಿ, ಒಂದು ಪ್ರಸ್ತಾವನೆಯನ್ನು ಸ್ವೀಕರಿಸಲು ಅದು ಸಾಕಾಗುವಷ್ಟು ಉತ್ತಮವಾಗಿದೆಯೇ ಎಂದು scorer ನಿರ್ಧರಿಸುತ್ತದೆ. ಅದರ ಅನುಮತಿಯಿಲ್ಲದೆ, ವಿಭಜನೆಯು ಅನಿಶ್ಚಿತ ಸ್ಥಿತಿಯಲ್ಲಿರುತ್ತದೆ (limbo).
Executor. ಮರವು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗುವಷ್ಟು ಸಣ್ಣ ಎಲೆ ನೋಡ್ಗಳಿಗೆ (leaf nodes) ತಲುಪಿದ ನಂತರ, executors ಅವುಗಳನ್ನು ವಹಿಸಿಕೊಳ್ಳಲು ಸ್ಪರ್ಧಿಸುತ್ತಾರೆ. ಅವರು ಕೇಂದ್ರ ಕ್ಯೂ (central queue) ಇಂದ ಅನುಮತಿಗಾಗಿ ಕಾಯುವುದಿಲ್ಲ. ಬದಲಾಗಿ, ಒಂದು ಕಾರ್ಯವನ್ನು ಯಾರು ಪಡೆಯುತ್ತಾರೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಅವರು timestamp protocol ಅನ್ನು ಬಳಸುತ್ತಾರೆ. ವಿಜೇತರು ಸ್ಥಳೀಯ LLM ಕರ (call) ಮೂಲಕ ಕೆಲಸವನ್ನು ನಿರ್ವಹಿಸುತ್ತಾರೆ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಪ್ರಸಾರ ಮಾಡುತ್ತಾರೆ.
Observer. ಇದು ಪ್ರತಿಯೊಂದು ನೆಟ್ವರ್ಕ್ಗೂ ಅಗತ್ಯವಿರುವ ಮೌನ ವೀಕ್ಷಕ (wallflower). ಇದು ಗಾಸಿಪ್ ಅನ್ನು ಮೌನವಾಗಿ ಕೇಳುತ್ತದೆ, ಚರ್ಚೆಗಳಿಂದ ಯೋಜನಾ ಮರವನ್ನು ಮರುನಿರ್ಮಿಸುತ್ತದೆ ಮತ್ತು ಓದಬಲ್ಲ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಅನ್ನು ಪ್ರಿಂಟ್ ಮಾಡುತ್ತದೆ. ಇದು ಎಂದಿಗೂ ಮಾತನಾಡುವುದಿಲ್ಲದ ಕಾರಣ, ಒಂದು ಪ್ರಮುಖ ಅಂಶವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ: ತಡವಾಗಿ ಸೇರುವ ಯಾರೇ ಆಗಲಿ ಕೇವಲ ಕೇಳಿಸಿಕೊಳ್ಳುವ ಮೂಲಕ ಇಡೀ ಯೋಜನೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.
ಸತ್ಯದ ಮೂಲವಾಗಿ ಗಾಸಿಪ್ (Gossip)
libp2p ಲೇಯರ್ ಡಿಸ್ಕವರಿ ಮತ್ತು ಮೆಸೇಜಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಏಜೆಂಟ್ಗಳು ಪ್ರೊಟೊಕೋಲ್ನ ಅಂತರ್ನಿರ್ಮಿತ ಪೀರ್ ಡಿಸ್ಕವರಿ ಮೂಲಕ ಪರಸ್ಪರರನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಾರೆ, ನಂತರ ಹಂಚಿಕೆಯ ಟಾಪಿಕ್ ಮೇಲೆ ಸಂದೇಶಗಳನ್ನು ಪ್ರಸಾರ ಮಾಡುತ್ತಾರೆ. ಇಲ್ಲಿ ಯಾವುದೇ ಅಧಿಕೃತ ಡೇಟಾಬೇಸ್ ಅಥವಾ ಅಧಿಕೃತ ಯೋಜನೆಯನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ Redis cache ಇಲ್ಲ.
ಪ್ರತಿಯೊಂದು ಪೀರ್ ತನ್ನದೇ ಆದ ಯೋಜನಾ ಮರದ ಪ್ರತಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ತಾನು ಕೇಳುವ ಗಾಸಿಪ್ ಆಧಾರದ ಮೇಲೆ ಅದನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡುತ್ತದೆ. ಒಂದು decomposer ಪ್ರಸ್ತಾವನೆಯನ್ನು ಪ್ರಸಾರ ಮಾಡಿದಾಗ, ಉಳಿದ ಎಲ್ಲಾ ನೋಡ್ಗಳು ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ, ಫಾರ್ಮ್ಯಾಟ್ ಅನ್ನು ವ್ಯಾಲಿಡೇಟ್ ಮಾಡುತ್ತವೆ ಮತ್ತು ಅದರ ಶಾಖೆಯನ್ನು (branch) ತನ್ನ ಸ್ಥಳೀಯ ಮರಕ್ಕೆ ಸೇರಿಸಿಕೊಳ್ಳುತ್ತವೆ. Scorers ಮತ ಚಲಾಯಿಸಿದಾಗ, ಎಣಿಕೆಯು ಅದೇ ರೀತಿಯಲ್ಲಿ ಹರಡುತ್ತದೆ. ಎರಡು executors ಒಂದೇ ಕಾರ್ಯಕ್ಕೆ ವಿಭಿನ್ನ ಹಕ್ಕುಗಳನ್ನು ಸಲ್ಲಿಸಿದರೆ, timestamp protocol ಸಂಘರ್ಷವನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ನೆಟ್ವರ್ಕ್ ಮೊದಲಿನ ಹಕ್ಕನ್ನು ಅಂಗೀಕರಿಸುತ್ತದೆ ಮತ್ತು ತಡವಾಗಿ ಬಂದದ್ದನ್ನು ಕೈಬಿಡುತ್ತದೆ.
ಕಾಲಾನಂತರದಲ್ಲಿ, ಮರವು ಮೂಲ ಗುರಿಯಿಂದ ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟ ಉಪಗುರಿಗಳ ಪದರಗಳ ಮೂಲಕ ಸಣ್ಣ ಸಣ್ಣ ಕಾರ್ಯಗಳವರೆಗೆ ಕೆಳಕ್ಕೆ ಬೆಳೆಯುತ್ತದೆ. ಈ ಪ್ರಕ್ರಿಯೆಯು ಬ್ಲಾಕ್ಚೈನ್ (blockchain) ಒಮ್ಮತಕ್ಕೆ ಬರುವಂತೆ ಇರುತ್ತದೆ, ಆದರೆ ಇಲ್ಲಿ ಪೇಲೋಡ್ (payload) ನಾಣ್ಯಗಳ ಲೆಡ್ಜರ್ ಬದಲಿಗೆ ಪ್ರಯಾಣದ ವಿವರ ಅಥವಾ ಸಾಫ್ಟ್ವೇರ್ ಸ್ಪೆಕ್ (software spec) ಆಗಿರುತ್ತದೆ.
ಮತದಾನ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸ್ಪರ್ಧೆ
ಪ್ರಜಾಪ್ರಭುತ್ವವು ದುಬಾರಿಯಾಗಿದೆ ಮತ್ತು ಈ ವ್ಯವಸ್ಥೆಯು ವಿಳಂಬದ (latency) ರೂಪದಲ್ಲಿ ಅದರ ಬೆಲೆಯನ್ನು ಪಾವತಿಸುತ್ತದೆ. ಸಾಕಷ್ಟು scorers ಒಪ್ಪಿಕೊಂಡರೆ ಮಾತ್ರ ಒಂದು ವಿಭಜನೆಯು ಗೆಲ್ಲುತ್ತದೆ. ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನೀವು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೀರಿ ಎಂಬುದರ ಮೇಲೆ ಆ ಮಿತಿಯು ಸರಳ ಬಹುಮತ ಅಥವಾ ಕಟ್ಟುನಿಟ್ಟಿನ ಕೋರಂ (quorum) ಆಗಿರಬಹುದು. Decomposers ಪ್ರಸ್ತಾಪಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನೆಟ್ವರ್ಕ್ ಹೆಚ್ಚಾಗಿ ಏಕಕಾಲದಲ್ಲಿ ಹಲವಾರು ಸ್ಪರ್ಧಾತ್ಮಕ ಮರಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ. ಅಂತಿಮವಾಗಿ ಒಂದು ಮರವು ಅಗತ್ಯ ಮತಗಳನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಅದರ ಉಪಗುರಿಗಳು ಕರಡು (draft) ಸ್ಥಿತಿಯಿಂದ ಸ್ವೀಕೃತ ಸ್ಥಿತಿಗೆ ಏರುತ್ತವೆ.
ಎಕ್ಸಿಕ್ಯೂಟರ್ಗಳು ಸಮನ್ವಯದ ಮತ್ತೊಂದು ಪದರವನ್ನು ಸೇರಿಸುತ್ತವೆ. ಗಾಸಿಪ್ ಚಾನಲ್ನಲ್ಲಿ (gossip channel) ಕಾರ್ಯಗಳು ಸಾರ್ವಜನಿಕವಾಗಿರುವುದರಿಂದ, ಹಲವಾರು ಎಕ್ಸಿಕ್ಯೂಟರ್ಗಳು ಒಂದೇ ಆಕರ್ಷಕ ಲೀಫ್ ನೋಡ್ ಅನ್ನು ಹಿಡಿಯಲು ಪ್ರಯತ್ನಿಸಬಹುದು. ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ ಪ್ರೊಟೊಕಾಲವು tiebreaker ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಕ್ಲೈಮ್ ಏಕಮುಖ (monotonic) ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಅತ್ಯಂತ ಮೊದಲನೆಯದನ್ನು ಪರಿಗಣಿಸುತ್ತದೆ. ಸೋತ ಎಕ್ಸಿಕ್ಯೂಟರ್ ಸರಳವಾಗಿ ಮುಂದಿನ ಲಭ್ಯವಿರುವ ಕಾರ್ಯಕ್ಕೆ ತೆರಳುತ್ತದೆ. ಇದು ಕಚ್ಚಾ ವಿಧಾನವಾಗಿದ್ದರೂ, ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸಾಲುಗಳನ್ನು (rows) ಲಾಕ್ ಮಾಡುವ ಕೇಂದ್ರೀಕೃತ ಶೆಡ್ಯೂಲರ್ನ ಅಗತ್ಯವನ್ನು ಇದು ತಪ್ಪಿಸುತ್ತದೆ.
ವಿನ್ಯಾಸದ ಮೂಲಕ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ (Resilience by Design)
ವ್ಯವಸ್ಥೆಗಳು ವಿಫಲವಾದಾಗ ಈ ಆರ್ಕಿಟೆಕ್ಚರ್ ತನ್ನ ಮೌಲ್ಯವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಒಂದು ವೇಳೆ ಡಿಕಂಪೋಸರ್ (decomposer) ಅರ್ಧದಷ್ಟು ಉಪಗುರಿಗಳನ್ನು (subgoals) ಪ್ರಸ್ತಾಪಿಸಿದ ನಂತರ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ, ಉಳಿದಿರುವ ಡಿಕಂಪೋಸರ್ಗಳು ಸ್ಪ್ಲಿಟ್ಗಳನ್ನು (splits) ನೀಡುತ್ತಲೇ ಇರುತ್ತವೆ. ಮರು-ಪ್ರಾರಂಭಕ್ಕಾಗಿ (respawn) ಕಾಯುತ್ತಾ ಯೋಜನೆ ನಿಂತುಹೋಗುವುದಿಲ್ಲ. ಒಂದು ವೇಳೆ ಸ್ಕೋರರ್ (scorer) ನೆಟ್ವರ್ಕ್ನಿಂದ ಹೊರಬಂದರೆ, ನೀವು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸೂಕ್ತವಾಗಿ ಗಾತ್ರಗೊಳಿಸಿದ್ದರೆ (sized appropriately) ಉಳಿದ ಮತದಾರರು (voters) ಕ್ವಾರಮ್ (quorum) ತಲುಪಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಇದರ ನಿಜವಾದ ಪ್ರಯೋಜನವೆಂದರೆ ಲೇಟ್ ಜಾಯ್ನ್ಸ್ (late joins). ಅರ್ಧ ಹಾದಿಯಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುವ ಹೊಸ ಏಜೆಂಟ್ಗೆ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಅಥವಾ...