Consistency & Consensus for System Design Interview (6): distributed transactions
PREV | HOME | NEXT | System Design Resource List
Don’t forget to get your copy of Designing Data Intensive Applications, the single most important book to read for system design interview prep!
Check out ByteByteGo’s popular System Design Interview Course
Introduction
Consensus, in the context of distributed systems, means having several nodes connected by a network to agree on something. It may sound trivial but amid the mayhem in a distributed system with failing nodes, new nodes joining, network delays, queue delays, GC pauses and such, the task to bring agreement among all nodes in the system becomes complex. Some of the scenarios where consensus is critical are listed below:
Leader Election
In single leader architectures, it is imperative that all nodes agree on which node is the current leader and at all times there should remain a single leader. In case of network partitions or node failures, another node may be elected as the leader. When a failover occurs incorrectly it is possible that two or more nodes consider themselves as the leader — a situation known as split brain — causing permanent data loss and/or data inconsistency.
