10. Consistency and Consensus

"An ancient adage warns, 'Never go to sea with two chronometers; take one or three.'" — Frederick P. Brooks Jr.

The two competing philosophies for dealing with replica inconsistency:

	Eventual consistency	Strong consistency
Stance	The fact that a system is replicated is MADE VISIBLE to the application; you as the developer are expected to deal with the inconsistencies and conflicts	Applications should NOT have to worry about internal details of replication; the system should BEHAVE AS IF IT WERE A SINGLE NODE
Used by	Multi-leader, leaderless replication	Single-leader, consensus-based systems
Advantage	Tolerates faults that break strongly consistent systems; inevitable if users make changes offline	Simpler for you, the application developer
Disadvantage	Can be difficult for applications to deal with	A performance cost, and SOME KINDS OF FAULT THAT AN EVENTUALLY CONSISTENT SYSTEM CAN TOLERATE CAUSE OUTAGES

If your replicas are located in datacenters with fast, reliable communication, STRONG CONSISTENCY IS OFTEN APPROPRIATE because its cost is acceptable.

The chapter's three movements:

The question	Where the chapter goes
① “Strong consistency” is vague	Linearizability — a precise definition
② How do you generate IDs and timestamps?	Logical clocks — closely connected
③ How do you get linearizability and fault tolerance?	Consensus

These topics are NOTORIOUS for being hard to implement correctly. It's very easy to build systems that behave fine when there are no faults but COMPLETELY FALL APART when faced with an unlucky combination of faults or message orderings that their designers hadn't considered.

10. Consistency and Consensus

Sections