Replication and consistency
Which answers may a client receive from replicas?
Slide contents
1. Replication and consistency
Which answers may a client receive from replicas?
2. After a successful write, another replica may lag
A client created T7, then read “not found”.
3. Replicas have their own application positions
Receiving a record and applying it are different events.
4. A leader orders commands within its group
The protocol replicates a client write.
5. Choose reply timing together with the guarantee
Local, quorum, and all-replica writes have different costs.
6. A strict read needs current authority
A nearby replica is not necessarily current.
7. An operation spans invocation to response
Seek an explanatory effect point inside that interval.
8. A later read cannot forget a completed write
Register x: write(1) completed before read began.
9. An overlapping read may return the old value
Read began before write(1) completed.
10. Sequential consistency preserves each process’s order
It need not preserve every real-time precedence.
11. Eventual consistency promises conditional convergence
Once updates stop, delivery and repair must continue.
12. A dependent update must not overtake its cause
“Task completed” depends on that task’s creation.
13. A session can protect its own observations
Read-your-writes and monotonic reads address different problems.
14. A session preserves dependencies among its actions
Monotonic writes and writes-follow-reads specify different links.
15. Choose a model by the history it forbids
“Consistency” alone is insufficient.
16. Quorums intersect within a fixed set
N=3, W=2, R=2: a common replica exists.
17. Replacing unavailable replicas changes the set
A sloppy quorum may use fallback nodes.
18. CAP uses precise meanings of C, A, and P
A concerns every nonfailed node.
19. An isolated reader cannot know a completed write
G1 wrote 1; G2 received no message.
20. Strict mode permits minority unavailability
A live isolated node need not serve a strict request.
21. A stale read must be an explicit choice
An etcd serializable read can be served locally.
22. Consistency still has a cost without partitions
PACELC adds the normal request path.
23. Creation verification and browsing have different goals
One system may expose explicitly different operations.
24. Which history breaks its selected guarantee?
State interval, mode, and allowed reply.
25. An experiment records modes, not merely reply counts
An operation history lets us check promises after failure.
Invocation and response
Client and key
Read mode
Partition side
26. Decisions for our service
Check a history for linearizability.
Distinguish ordering, session, and convergence guarantees.
Explain CAP and the normal cost of replication.