This chapter is from the book
This chapter is from the book
This chapter is from the book
Competing Updates
Suppose two different users, Alice and Bob, are connecting to two different cluster nodes to execute their requests. Alice wants to move 30 widgets from Boston to London, while Bob wants to move 40 widgets from Boston to Pune (Figure 2.6).
)
Figure 2.6 Competing updates
How should the cluster resolve this? We can’t have any node just decide to do an update because we’d quickly run into inconsistency hell as we try to figure out how to get Boston to store antimatter widgets. One of the most straightforward approaches is Leader and Followers, where one of the nodes is marked as the leader, and the others are considered followers. In this situation, the leader handles all updates and broadcasts those updates to the followers. Let’s say Neptune is the leader in this cluster. Then, Jupiter will forward Alice’s A1 request to Neptune (Figure 2.7).
)
Figure 2.7 Leader handling all the updates
Neptune now gets both update requests, so it has the sole discretion as to how to deal with them. It can process the first one it receives (Bob’s B1) and reject A1 (Figure 2.8).
)
Figure 2.8 Leader rejecting requests for insufficient widgets