Try This First: Can The Read Miss The Write?
Before I explain anything, I want you to try a small puzzle. Take a pen if you like.
You keep one piece of data, say a bank balance of 100. To be safe from a broken machine, you keep five copies of it, on five different machines. Call them A, B, C, D and E. Each machine holds the same number.
Now somebody changes the balance to 70. The change is sent to all five machines, but only three of them answer "done" in time. The other two are slow, or busy, or briefly cut off. We tell the user "saved" after those three answers.
A moment later, somebody else wants to read the balance. They also do not wait for all five machines. They ask any three, and they take the newest answer they get.
Here is the question. Can the read pick three machines that the write never reached, and so show the old balance of 100?
Engineers call each of those groups of machines a quorum, and this puzzle is the heart of read and write quorums in distributed systems. But do not read on yet. Try to find three machines for the read that share nobody with the three machines that took the write.
This is the setting for the whole lesson. Every machine holds a copy of the same value. A copy kept on another machine like this is called a replica, and the number of copies is the first number we will care about.
Pick any three circles for the write, then try to pick three different circles for the read. You will run out of circles before you finish. The next slide counts why.
If you tried, you probably got stuck. With three machines taken by the write, only two are left over, D and E for example. The read needs three. So the third machine the read asks must be one of the three that has the new balance.
That is the main idea of this lesson. The rest of the lesson pins names onto it, checks it with a program, and then shows the places where this simple counting is not enough. Those places are where real systems lose data, so they matter as much as the counting.