📊System Architecture
Introduction
This architecture implements a basic distributed consensus protocol, where nodes must agree on state changes before they are committed. The system ensures consistency across nodes by requiring explicit acknowledgment and commitment phases before any state changes are finalized.
The key feature of this design is fault tolerance and consistency - no state change can occur without proper agreement between the nodes, helping to maintain data consistency across the distributed system.
Breaking Down each Component
This architecture diagram illustrates a distributed consensus system with two nodes and a client. Let me break down the components and their interactions -
Client
It can send proposals to either Node 1 or Node 2.
It acts as an external entity initiating state changes in the system.
Node Structure
Listener: Receives incoming network messages and connections.
Message Handler: Processes received messages and coordinates responses.
State: Stores the current state of the node.
Proposal Acknowledgment: Tracks which nodes have acknowledged proposals.
Communication Flow
Between nodes, there are six types of messages that can be exchanged -
a) Proposal: A node suggesting a state change.
b) Acknowledgment: A node accepting another node's proposal.
c) Commit: A node confirming a state change should be applied.
Message Flow Pattern
When a proposal is made (either by client or a node) -
a) The proposal is received by the listener.
b) Passed to the message handler.
c) Message handler updates state if needed.
d) Message handler tracks acknowledgments.
e) Other nodes respond with acknowledgments.
f) Once enough acknowledgments are received, a commit message is sent.
Consensus Process
The multiple lines connecting Node 1 and Node 2 represent the back-and-forth communication needed to reach consensus -
a) Initial proposal
b) Acknowledgment of the proposal
c) Final commit once agreement is reached
Last updated