@travisjeffery

The book in many places stands for Raft consensus algorithm being able to replicate all data across the servers. The truth is that data is EVENTUALLY consistent across the servers and Raft itself is based on assumption that all requests are handled by the leader - not the followers. This also includes read operations.

A client can observe inconsistent state across multiple calls with an introduced approach (load-balancing across the followers). For replication Raft uses a majority rule so it returns to the client after the log entry is replicated on a majority of the servers. But REPLICATED indeed doesn’t mean APPLIED (so applied to the state machine). Moreover, the majority of the servers doesn’t mean all the servers. The followers should be considered as inconsistent. Only the leader guarantees consistency. And it questions the correctness of the built distributed system.

Chapter 9 is extremely useful and it does its job - so perfectly describes the concept behind gRPC client-side load-balancing. But I think it would be great if the book explicitly explained the drawbacks of chosen approach and highlight the fact that what has been done for educational purposes is not entirely true and production ready.