Virtual Synchrony

A group communication model that guarantees all members of a process group observe the same sequence of view changes (membership changes) and message deliveries relative to those views. It underpins fault-tolerant replicated systems by ensuring that no message crosses a view boundary inconsistently across surviving members.

Practical example

A replicated session-store cluster using JGroups delivers a batch of cache invalidation messages; when one replica crashes mid-broadcast, the flush protocol ensures every surviving replica either applied the invalidation before the new view was installed or none did, preventing a stale-cache split among survivors.

Virtual synchrony, formalized by Ken Birman and Thomas Joseph in the Isis toolkit, defines a contract between a group communication subsystem and applications built atop it: every member of a process group perceives the same ordered sequence of view changes, and every regular message is delivered in the context of exactly one view, consistently across all members who survive into the next view. If a node fails mid-broadcast, the protocol guarantees that either all surviving members deliver the message before the next view is installed, or none do — there is no scenario where one surviving replica applies a state-mutating message that another surviving replica never saw.

Under the hood, this requires a flush protocol at every view change: before a new view is installed, all members must acknowledge receipt of all messages sent in the prior view, guaranteeing no in-flight message spans the boundary ambiguously. This is distinct from simple reliable multicast because it couples message delivery ordering to membership ordering — you cannot reason about one without the other. Total order (atomic broadcast) is often layered on top for state-machine replication, but virtual synchrony itself only guarantees view-synchronous delivery, not global total order, unless explicitly extended.

Partition handling: classical virtual synchrony assumes a primary-partition model — only one partition continues operating after a network split, and minority partitions block or shut down, which is what makes it unsuitable for AP-style systems that want partition tolerance with progress on both sides.
Extended virtual synchrony (EVS): variants allow multiple concurrent views (one per partition) to proceed independently, later reconciling state on merge — the reconciliation logic is notoriously hard to get right and is a common source of subtle bugs in systems like Spread and legacy JGroups configurations.
Cost: the flush-before-install step is a synchronization barrier; under churn (frequent membership changes) throughput can collapse because every view transition stalls new sends until in-flight messages drain.

Architecturally, virtual synchrony predates and heavily influenced modern consensus-based replication (Raft, Paxos-based state machines) but differs in intent: it is a group communication primitive for building replicated services (e.g., replicated caches, pub/sub coordination layers, cluster membership services), not a consensus algorithm for a single agreed value. Systems like early JGroups, Isis2, and Spread Toolkit implement it directly; modern systems more often achieve equivalent guarantees by layering epoch/generation fencing over a consensus-backed membership log (e.g., Raft configuration changes), effectively reconstructing virtual-synchrony-like semantics without naming them as such.