Viewstamped Replication: Consensus and Replication

1. Introduction and Core Concepts

Viewstamped Replication (VR) is a foundational consensus and replication protocol for building fault-tolerant distributed services. Originally proposed by Brian Oki and Barbara Liskov in 1988 and later revitalized in a 2012 paper by Liskov and Cowling, viewstamped replication provides linearizable replication of a deterministic state machine across a group of replicas, tolerating crash failures while maintaining availability and consistency. It is the direct intellectual ancestor of modern protocols like Raft and Zab, and understanding VR is essential for anyone designing databases, coordination services, or replicated log systems.

At its core, viewstamped replication is a primary-backup protocol with a strong consistency guarantee. The system consists of 2f+1 replicas to tolerate f crash failures, where one replica acts as the primary (leader) in a given view and the rest act as backups. Clients interact only with the primary, which orders client requests, replicates them to backups, and commits them once a quorum acknowledges receipt. The concept of a "view" is central: a view is a numbered configuration with a designated primary, calculated as view_number mod N. When the primary fails, the system moves to a new view with a different primary through a view change protocol.

Why does viewstamped replication matter today? In an era of cloud-native databases and globally distributed services, developers must choose replication protocols that balance simplicity, performance, and correctness. Viewstamped replication offers a clean separation between the normal operation path, which is highly efficient, and the failure handling paths for view changes and recovery. Unlike Paxos, which is notoriously difficult to understand and implement correctly, VR provides an intuitive primary-driven flow that maps naturally to how many production systems actually work. Its explicit handling of client deduplication, reconfiguration, and witness replicas also makes it a complete blueprint for a practical system, not just a theoretical consensus algorithm.

Core Assumptions and Guarantees

Viewstamped replication assumes a crash-failure model, not Byzantine failures. Replicas may crash and recover with stable storage, but they do not behave maliciously. The network is asynchronous and may drop, delay, or reorder messages, but it does not corrupt them undetectably. The protocol guarantees linearizability for client operations: every operation appears to execute atomically at some point between its invocation and completion, and all replicas apply committed operations in the same order. It also guarantees durability: once an operation is committed and acknowledged to the client, it will survive f simultaneous failures and will never be lost, even across view changes.

Another key concept is the operation number (op-number), which is a monotonically increasing log index assigned by the primary. Along with the view number and commit number, these three integers define the entire ordering and durability state of the system. The commit number represents the highest op-number known to be committed, meaning it has been replicated to a quorum and can be safely applied to the application state machine. Backups learn the commit number via piggybacking on PREPARE messages, keeping their state machines eventually consistent with the primary without extra round trips.

2. How It Works

The viewstamped replication protocol operates in four distinct sub-protocols: normal operation, view change, recovery, and reconfiguration. Normal operation is the common case where the primary is healthy and processing client requests. The primary receives a client request, assigns it the next operation number, appends it to its local log, and broadcasts a PREPARE message containing the view number, op-number, request payload, and its current commit number to all backups. Each backup validates that the view number matches its own, that it has not already received a higher op-number, appends the request to its log, and replies with PREPARE_OK. Once the primary receives PREPARE_OK from f other replicas including itself, it considers the operation committed, advances its commit number, applies the operation to its state machine, and replies to the client. Commit notification to backups is then piggybacked on subsequent PREPARE messages or sent as an explicit COMMIT.

Failure detection and view change are driven by timeouts. Backups monitor the primary; if they receive no PREPARE or heartbeat within a configurable interval, they suspect the primary has failed and initiate a view change. A replica entering view change increments its view number, changes its status to VIEW_CHANGE, and broadcasts a START_VIEW_CHANGE message. When a replica receives f+1 START_VIEW_CHANGE messages for a higher view, it acknowledges the new view and sends a DO_VIEW_CHANGE message to the node that will be the primary in the new view. This message contains its entire log, its op-number, commit number, and view number. The new primary waits for f+1 DO_VIEW_CHANGE messages including its own, selects the log with the highest view and op-number to ensure no committed operation is lost, and then broadcasts a START_VIEW message that installs the new log and view on all replicas. At this point, normal operation resumes.

Recovery handles the case where a replica crashes and restarts with no memory of its prior state, or with stale stable storage. A recovering replica broadcasts a RECOVERY message with a nonce to all other replicas. Replicas in NORMAL state reply with a RECOVERY_RESPONSE containing their view number, op-number, commit number, log, and whether they are the primary. The recovering replica waits for f+1 responses and adopts the state from the response with the highest view number, or from the primary if one responded. This ensures a recovered replica never overwrites committed history. Reconfiguration, the fourth protocol, allows the set of replicas to change dynamically without downtime. It is implemented as a special committed operation that transitions the system from an old configuration to a new one, using overlapping quorums to ensure safety during the transition.

The Role of the Client and Exactly-Once Semantics

Clients in viewstamped replication are not passive. Each client is assigned a unique client ID and maintains a monotonically increasing request number. Replicas maintain a client table that maps client_id to the highest request_id seen and its corresponding response. This table is part of the replicated state and is used to provide exactly-once semantics despite client retries. If a client does not receive a response due to a primary failure, it retries with the same request_id against the new primary. The new primary checks the client table: if the request was already committed, it returns the cached response without re-executing; if it is new, it processes it normally. This deduplication is critical for building correct higher-level applications where operations like bank transfers or inventory decrements must not be applied twice.

Quorums and View Numbers

All decisions in VR require a quorum of f+1 replicas out of 2f+1. This quorum intersection property guarantees that any two quorums overlap in at least one replica, ensuring that any committed operation will be visible to any future view change quorum. View numbers act as logical clocks that totally order primary epochs. A replica will ignore any message from an older view, and will step forward to a newer view when it learns of one. This simple rule prevents split-brain scenarios where an old primary, partitioned from the network, continues to act as leader and diverges the log.

3. Implementation

Implementing viewstamped replication correctly requires careful management of persistent state, message handling, and timers. The following Python examples illustrate the core data structures and protocol logic in a simplified, single-process simulation. In a production system, you would replace in-memory calls with RPCs, add persistent logging to disk, and implement proper timeout and retransmission logic.

The first block defines the replica state. Every replica must persist view_number, op_number, commit_number, the log, and the client table to stable storage before acknowledging any message, so that a crash does not cause committed data to be forgotten.

# Viewstamped Replication - Replica State
from typing import Dict, List, Optional
import enum

class ReplicaStatus(enum.Enum):
    NORMAL = "NORMAL"
    VIEW_CHANGE = "VIEW_CHANGE"
    RECOVERING = "RECOVERING"

class Replica:
    def __init__(self, replica_id: int, num_replicas: int):
        self.replica_id = replica_id
        self.num_replicas = num_replicas
        self.view_number = 0
        self.op_number = 0
        self.commit_number = 0
        self.log: Dict[int, dict] = {}  # op_number -> request
        self.status = ReplicaStatus.NORMAL
        self.primary_id = 0  # view_number % num_replicas

    def is_primary(self) -> bool:
        return self.replica_id == (self.view_number % self.num_replicas)

    def quorum_size(self) -> int:
        return (self.num_replicas // 2) + 1

The second block implements the normal operation path. Note how the primary batches the commit notification and how backups update their commit number based on the primary's piggybacked value. The apply_state_machine function must be deterministic and applied in strict op-number order.

# Normal Operation: Primary Replication Path
def handle_client_request(primary: Replica, request: dict, backups: List[Replica]):
    # Only primary processes client requests in current view
    if not primary.is_primary():
        return {"error": "Not primary", "primary_hint": primary.primary_id}

    if primary.status != ReplicaStatus.NORMAL:
        return {"error": "Replica not in NORMAL state"}

    # Assign next operation number and append to log
    primary.op_number += 1
    op_num = primary.op_number
    primary.log[op_num] = request

    # Phase 1: Send PREPARE to all backups
    prepare_msg = {
        "type": "PREPARE",
        "view": primary.view_number,
        "op_number": op_num,
        "request": request,
        "commit_number": primary.commit_number
    }

    acks = 1  # primary counts for itself
    for backup in backups:
        if backup.view_number == primary.view_number:
            # Backup validates view and op_number ordering
            if op_num > backup.op_number:
                backup.log[op_num] = request
                backup.op_number = op_num
                # Backup updates commit_number if primary is ahead
                if primary.commit_number > backup.commit_number:
                    backup.commit_number = primary.commit_number
                acks += 1  # Simulate PREPARE_OK

    # Phase 2: Commit if quorum acknowledged
    if acks >= primary.quorum_size():
        primary.commit_number = op_num
        # Send COMMIT to backups (piggybacked on next PREPARE in practice)
        for backup in backups:
            if op_num > backup.commit_number:
                backup.commit_number = op_num
                # Apply to state machine up to commit_number
                apply_state_machine(backup, backup.commit_number)
        apply_state_machine(primary, primary.commit_number)
        return {"status": "COMMITTED", "op_number": op_num}
    else:
        return {"status": "RETRY", "reason": "Quorum not reached"}

def apply_state_machine(replica: Replica, up_to: int):
    # Apply all operations <= commit_number in order
    for op in range(replica.commit_number, up_to + 1):
        if op in replica.log:
            # execute(replica.log[op]) - deterministic state transition
            pass

The third block shows the view change protocol, which is the most complex part to get right. The new primary must choose the correct log to avoid losing committed entries. The rule is to pick the log from the DO_VIEW_CHANGE message with the largest view number, and if views are equal, the largest op-number.

# View Change Protocol - Handling Primary Failure
def start_view_change(replica: Replica, all_replicas: List[Replica]):
    # Triggered when backup detects primary timeout
    replica.status = ReplicaStatus.VIEW_CHANGE
    replica.view_number += 1
    new_view = replica.view_number

    # Broadcast START_VIEW_CHANGE to all replicas
    start_view_change_msgs = []
    for r in all_replicas:
        if r.replica_id != replica.replica_id:
            # In real implementation, send via network
            r.receive_start_view_change(new_view, replica.replica_id)

    # Check if quorum agrees to move to new view
    # If f failures tolerated, need f+1 START_VIEW_CHANGE messages
    return new_view

def receive_start_view_change(replica: Replica, new_view: int, sender_id: int):
    if new_view > replica.view_number:
        replica.view_number = new_view
        replica.status = ReplicaStatus.VIEW_CHANGE
        # Acknowledge by sending START_VIEW_CHANGE as well

def do_view_change(new_primary: Replica, all_replicas: List[Replica]):
    # New primary is determined by view_number % num_replicas
    assert new_primary.is_primary()

    # Collect DO_VIEW_CHANGE messages from f+1 replicas
    # Each contains: view, log, op_number, commit_number
    collected_logs = []
    for replica in all_replicas:
        if replica.status == ReplicaStatus.VIEW_CHANGE:
            collected_logs.append({
                "op_number": replica.op_number,
                "commit_number": replica.commit_number,
                "log": dict(replica.log),
                "view": replica.view_number
            })

    # New primary selects log with highest op_number
    # and commit_number to preserve committed operations
    if collected_logs:
        latest = max(collected_logs, key=lambda x: (x["view"], x["op_number"]))
        new_primary.log = dict(latest["log"])
        new_primary.op_number = latest["op_number"]
        new_primary.commit_number = latest["commit_number"]

    # Broadcast START_VIEW with new log to all replicas
    for replica in all_replicas:
        replica.view_number = new_primary.view_number
        replica.log = dict(new_primary.log)
        replica.op_number = new_primary.op_number
        replica.commit_number = new_primary.commit_number
        replica.status = ReplicaStatus.NORMAL
        replica.primary_id = new_primary.replica_id

    new_primary.status = ReplicaStatus.NORMAL

The final block demonstrates recovery and client deduplication, two features that make VR a complete system. Without the client table, retries after a view change could cause duplicate execution. Without the recovery protocol, a restarted replica could not rejoin safely.

# Recovery Protocol and Exactly-Once Client Handling
client_table: Dict[str, dict] = {}  # client_id -> {request_id, response}

def handle_recovery(recovering: Replica, all_replicas: List[Replica]):
    # Recovering replica has lost state and needs to catch up
    recovering.status = ReplicaStatus.RECOVERING
    recovering.view_number = 0

    # Send RECOVERY message to all replicas
    responses = []
    for replica in all_replicas:
        if replica.replica_id != recovering.replica_id and replica.status == ReplicaStatus.NORMAL:
            # Nonce prevents replay attacks in real protocol
            nonce = 12345  # random nonce
            resp = replica.handle_recovery_request(nonce, recovering.replica_id)
            if resp is not None:
                responses.append(resp)

    # Need f+1 RECOVERY_RESPONSE messages
    if len(responses) >= (recovering.num_replicas // 2) + 1:
        # If any response indicates primary is in same view, use its state
        primary_resp = next((r for r in responses if r["is_primary"]), None)
        chosen = primary_resp if primary_resp else responses[0]

        recovering.view_number = chosen["view"]
        recovering.op_number = chosen["op_number"]
        recovering.commit_number = chosen["commit_number"]
        recovering.log = dict(chosen["log"])
        recovering.status = ReplicaStatus.NORMAL

def handle_client_with_dedup(replica: Replica, client_id: str, request_id: int, request: dict):
    # Ensure exactly-once semantics via client table
    last_entry = client_table.get(client_id)

    if last_entry is not None and request_id < last_entry["request_id"]:
        # Stale request, ignore
        return last_entry["response"]

    if last_entry is not None and request_id == last_entry["request_id"]:
        # Duplicate, return cached response without re-executing
        return last_entry["response"]

    # New request - process via normal protocol if primary
    if replica.is_primary() and replica.status == ReplicaStatus.NORMAL:
        result = handle_client_request(replica, request, [])
        # Cache response for deduplication
        client_table[client_id] = {"request_id": request_id, "response": result}
        return result
    else:
        return {"error": "Forward to primary", "primary": replica.primary_id}

4. Step-by-Step Example

Consider a deployment with N=3 replicas (R0, R1, R2) tolerating f=1 failure, initially in view 0 where R0 is primary. The commit number and op-number are both 0, and all logs are empty. A client C1 sends request X with request_id=1 to R0.

Step 1: R0 receives X, assigns op-number=1, appends X to its log, and broadcasts PREPARE(view=0, op=1, commit=0, request=X) to R1 and R2. R1 and R2 validate the view, append X at op-number 1, update their op-number to 1, and reply PREPARE_OK. R0 waits for f+1=2 acknowledgments; with its own log plus one backup, it has a quorum. R0 sets commit_number=1, applies X to its state machine, and replies to C1 that X is committed. The commit is piggybacked on the next PREPARE, but R1 and R2 will apply X once they learn commit_number=1.

Step 2: Client C2 sends request Y to R0. R0 assigns op-number=2, broadcasts PREPARE(view=0, op=2, commit=1, request=Y). Suppose R1 acknowledges but R2 is slow and does not reply before R0's timeout. R0 still has 2 acknowledgments (itself + R1), so it commits Y, sets commit_number=2, and replies to C2. R1 learns commit_number=1 from the PREPARE and applies X. R2 eventually receives the PREPARE, appends Y, but has not yet learned that Y is committed.

Step 3: R0 crashes before sending any further COMMIT messages. R1 and R2 detect the failure via timeout and start a view change to view 1, where R1 will be primary (1 % 3 = 1). Both send START_VIEW_CHANGE(view=1) and then DO_VIEW_CHANGE to R1 containing their logs. R1 has log [X, Y] with op-number=2, commit=1; R2 has log [X, Y] with op-number=2, commit=0. R1 collects f+1=2 messages, picks the log with the highest op-number (both equal, but R1's commit is higher), and broadcasts START_VIEW(view=1, log=[X,Y], op=2, commit=1). Upon receiving START_VIEW, R2 replaces its log, sets view=1, op=2, commit=1, applies X, and enters NORMAL state. R1 also enters NORMAL as the new primary.

Step 4: Client C2, having received a commit acknowledgment for Y, does not retry. Client C1, if it had not received an acknowledgment for a later request Z sent just before the crash, would retry Z with the same request_id to R1. R1 checks the client table: if Z was already committed in the old view, the table will contain its response and R1 will return it without re-appending; otherwise it will process Z as op-number=3 in view 1. This walk-through shows how VR never loses a committed operation: Y was committed in view 0 and survived the view change because at least one member of any view-change quorum (R1) had it.

5. Complexity Analysis

Viewstamped replication is optimized for the common case where the primary is stable. Normal operation requires a single round trip from primary to backups and back, which is optimal for strong consistency. The message complexity is linear in the number of replicas, and the latency is dominated by network round-trip time plus disk write latency if you persist the log synchronously, which you must for correctness.

View change and recovery are more expensive because they require collecting state from a quorum and transferring the entire log. In the worst case, the log could be very large, so practical implementations use checkpoints and log truncation to bound this cost. The time to complete a view change is typically 2-3 round trips plus the time to detect failure, which is governed by the timeout value. Choosing timeouts involves a trade-off: too short causes spurious view changes during transient network delays, too long increases unavailability after a real failure.

Space complexity is dominated by the log and the client table. The log grows unboundedly unless truncated via checkpoints. Each replica stores the full log, so total storage is O(N * L) where L is the number of operations since the last checkpoint. The client table is O(C) where C is the number of clients, which is usually much smaller than L.

In Big O terms, normal operation latency is O(1) network round trips, which is optimal. Throughput scales with the primary's ability to batch and pipeline PREPARE messages. View change latency is O(D + RTT) where D is the failure detection timeout. For most workloads, VR provides throughput within 10-20% of an unreplicated system when the network is fast and batching is used, because the primary does not need to wait for all backups, only a quorum.

6. Variations and Optimizations

Several important optimizations make viewstamped replication practical for high-throughput systems. The most impactful is request batching and pipelining. Instead of waiting for a quorum acknowledgment before sending the next PREPARE, the primary can pipeline multiple PREPARE messages, keeping the network and disks busy. Batching allows the primary to pack multiple client requests into a single PREPARE message, amortizing the per-message overhead and disk fsync cost. Modern implementations can achieve tens of thousands of operations per second with batch sizes of 100-1000 requests.

Witness replicas and flexible quorums are another optimization for reducing cost. In a 3-replica deployment, all replicas are full replicas that store the log and execute the state machine. For larger deployments, you can use witnesses that participate in quorums for view changes and recovery but do not store the full log or execute requests. This reduces storage and CPU cost while maintaining the same fault tolerance. The VR Revisited paper also describes an optimization where the commit number is piggybacked and backups apply operations lazily, avoiding an extra COMMIT round trip entirely.

Checkpointing and log truncation are essential for bounding storage and recovery time. Periodically, replicas take a snapshot of the application state at a given commit number and discard log entries up to that point. During view changes, only log entries after the latest checkpoint need to be transferred. Without checkpointing, a long-running system would eventually run out of disk and view changes would become prohibitively expensive. Fast recovery can be further optimized with incremental log transfer and by having the new primary send only missing suffixes rather than the entire log.

VR Revisited and Modern Enhancements

The 2012 VR Revisited protocol introduced reconfiguration as a first-class operation, allowing the replica set to change without manual intervention. It also clarified the recovery protocol with nonces to prevent a recovering replica from being tricked by stale messages from an old view. More recent variants include Viewstamped Replication with Fast Path, which allows read-only requests to be served by the primary without full replication if leases are used, and protocols that combine VR with chain replication for better read scalability. Some systems implement speculative execution where backups execute requests before they are committed and roll back if the view changes, trading complexity for lower latency.

7. Real-World Applications

While viewstamped replication itself is less famous than Raft, its ideas power many production systems. The protocol directly influenced the design of VMware's vSphere replication, Apache Kafka's early replication discussions, and several proprietary financial trading platforms where deterministic state machine replication is critical. More broadly, any system that needs linearizable replication with a primary-backup architecture can be seen as an instantiation of VR principles.

In distributed databases, VR-style replication is used for metadata services and for replicating the write-ahead log of a single shard. For example, a sharded SQL database might use VR to replicate each shard's log across three availability zones, ensuring that a zone failure does not lose committed transactions. In coordination services similar to ZooKeeper or etcd, the core consensus log is often implemented with a VR-like protocol, though many newer systems explicitly use Raft. The key advantage in these settings is the simplicity of the primary-driven log: the database engine can treat the replicated log as a durable commit queue and apply it to its storage engine asynchronously.

Viewstamped replication is also well-suited for replicated state machines that require exactly-once processing, such as stream processing engines, job schedulers, and configuration management services. Because the client table provides built-in deduplication, these systems do not need an external idempotency layer.

When choosing VR for a web-scale service, consider the deployment environment. VR performs best in low-latency data center networks where the primary can quickly reach backups. In geo-replicated settings with high inter-region latency, the single-primary bottleneck may become a limitation, and multi-leader or quorum-read protocols might be more appropriate. For most intra-datacenter replication, however, VR's simplicity and performance make it an excellent choice.

8. Comparison with Alternatives

Viewstamped replication occupies a specific point in the design space of consensus protocols. It is often compared with Paxos, Raft, and Zab (ZooKeeper Atomic Broadcast). All four provide linearizable replication for crash failures, but they differ significantly in understandability, message patterns, and practical completeness.

Paxos is the classical consensus protocol and is highly general, but it is notoriously difficult to implement correctly for log replication. Multi-Paxos, the variant used for replication, resembles VR's normal operation but lacks VR's explicit view change and recovery protocols, leaving many details to the implementer. Raft was explicitly designed for understandability and is very similar to VR: both are primary-backup, use terms/views as logical clocks, and replicate via AppendEntries/PREPARE. The main difference is that Raft's leader election is more elaborate with randomized timeouts and RequestVote RPCs, while VR's view change is simpler and deterministically rotates the primary. Zab is the protocol behind ZooKeeper; it is also primary-backup but adds a synchronization phase after election to ensure the new leader has the most recent history, similar to VR's START_VIEW.

In practice, the choice between VR and Raft often comes down to ecosystem and familiarity. Raft has more open-source implementations and educational material, while VR has a slightly simpler view change and a more complete specification for client handling and reconfiguration in its Revisited form. Both are excellent choices and far easier to implement correctly than Paxos. If you need Byzantine fault tolerance, you must look beyond all four to protocols like PBFT or HotStuff.

9. Common Mistakes and Best Practices

Implementing viewstamped replication correctly is subtle, and several common mistakes can violate safety or liveness. The most dangerous mistake is failing to persist state before acknowledging. A replica must write its view_number, op_number, log entry, and client table to stable storage synchronously before sending PREPARE_OK or DO_VIEW_CHANGE. If it acknowledges in memory and then crashes, a committed operation could be lost during the next view change. Always use fsync or equivalent and consider group commit to amortize disk latency.

Another frequent pitfall is incorrect quorum handling during view change. The new primary must wait for f+1 DO_VIEW_CHANGE messages and must choose the log with the highest view number, not just the longest log. Choosing the longest log can discard a committed operation that was replicated to a quorum but is not present on the replica with the longest uncommitted suffix. Similarly, a replica must not consider an operation committed until it has heard from a quorum in the same view; an operation replicated in an old view but not committed before the view change must be re-proposed or discarded based on the new primary's log.

Timeout tuning and failure detection are common sources of liveness bugs. If timeouts are too aggressive, the system will thrash between views without making progress. Implement randomized timeouts and exponential backoff for view change initiation, similar to Raft's approach, to reduce contention. Also, ensure that clients correctly handle primary hints: when a backup replies "not primary," the client should redirect to the hinted primary but must also handle the case where the hint is stale due to a concurrent view change. The client should retry with backoff and eventually broadcast to all replicas to discover the new primary.

Best Practices Checklist

• Persist all protocol state (view, op-number, log, client table, commit number) to stable storage before sending any acknowledgment. Use write-ahead logging and batch fsyncs.
• Implement checkpointing early. Define a checkpoint interval (e.g., every 10,000 operations or 100MB of log) and ensure START_VIEW transfers only the delta since the checkpoint.
• Use nonces and view validation in recovery to prevent a recovering replica from learning stale state from a partitioned replica. Always collect f+1 RECOVERY_RESPONSE messages.
• Make the state machine deterministic and ensure apply is idempotent up to commit_number. Never apply an operation twice or out of order.
• Test with fault injection: crash the primary during PREPARE, partition the network during view change, and restart replicas with empty disks. Use a model checker or simulation tester to explore interleavings.
• Monitor view change frequency, commit latency, and log growth as key health metrics. Alert if view changes occur more than once per minute under stable network conditions.

10. Interview Questions

Viewstamped replication is a frequent topic in distributed systems interviews for senior backend and infrastructure roles. Interviewers use it to assess understanding of consensus, failure handling, and trade-offs. Below are common questions with guidance on what a strong answer should cover.

Q1: How does viewstamped replication ensure that a committed operation is never lost during a view change? A strong answer should explain quorum intersection: an operation is committed only after it is replicated to f+1 replicas. Any future view change quorum of f+1 replicas must intersect the commit quorum in at least one replica that has the operation. The new primary collects DO_VIEW_CHANGE from f+1 replicas and picks the log with the highest view/op-number, guaranteeing the committed operation is included. Mention that this relies on the primary not advancing commit_number until a quorum acknowledges, and that the commit number itself is also propagated via DO_VIEW_CHANGE.

Q2: What is the difference between viewstamped replication and Raft? When would you choose one over the other? Discuss that both are primary-backup log replication protocols with similar normal paths, but Raft uses randomized election timeouts and RequestVote, while VR deterministically rotates the primary via view_number % N and uses START_VIEW_CHANGE. Raft's leader election is more robust to timing issues, while VR's view change is simpler to reason about. Mention