Primary-backup architecture assigns one replica as the primary: writes go there, while the primary broadcasts updates to replicas that serve local reads. This separates write coordination from replicated read access. section 4.8
In Viewstamped Replication, the primary orders client requests and sends them to backups. Backups acknowledge replication, and the primary replies after a quorum acknowledges. Views identify the active primary; failed primaries trigger a view change. section 4.7
A minimal replicated key-value store follows this protocol:
- Accept PUT operations only on the primary, then broadcast each Put update to replicas. section 4.8
- Let a replica join by sending its network address to the primary. section 4.8
- Send a complete Snapshot when the replica joins, then apply later updates incrementally. section 4.8
- Read locally from the replica after synchronization; before joining, it has no primary data. section 4.8
Replicated in-memory key-value store
Run the primary on port 8080 and store `a = 1` and `b = 2`. Start a replica on port 8081; `GET a` initially returns “Not found.” After `JOIN localhost:8080`, the replica receives a snapshot and returns `a -> 1` and `b -> 2`. A later primary write, `PUT c 3`, becomes readable on the replica as `c -> 3`. section 4.8
Figure 4.8 Example of Viewstamped Replication normal operation message flow
Trace normal Viewstamped Replication message flow between the client, primary, and backups. section 4.7
