8 Replication

Redundancy is the duplication and coordination of subsystems to improve reliability and/or scalability. There are two types: (1) Static redundancy: the set of components and their interactions do not change during the system’s lifetime (common in hardware). (2) Dynamic redundancy: components and their interactions can change over time (common in software).

Redundancy often aids scalability by distributing data across multiple nodes and enabling load partitioning (for example, round-robin across replicas). However, the relationship is not straightforward—coordination overheads or consistency requirements can also decrease scalability.

Durability ensures that once a transaction is committed, its effects are permanent—no “backtracking.” In real systems subject to failures, a single component can fail and break promises (for example, shipping goods without actually capturing payment). Redundancy avoids single points of failure and helps uphold durable promises despite crashes or recoveries.

Duplicating components alone does not create a reliable system; the duplicates must be coordinated so they behave like one coherent component. Coordination can be simple (load balancing) or complex (consensus). For example, three replicated logic gates coordinated by a majority vote can tolerate one failure while preserving correct output.

Replication represents a single logical object by multiple, identical physical objects (replicas) to improve reliability. Replication transparency is the system’s ability to hide the fact that multiple replicas exist and present the illusion of a single object, balancing consistency, availability, and latency.

The system is partially synchronous and components can suffer Crash-Stop, Omission, and Crash-Recovery failures. Communication happens over unreliable, point-to-point links, which makes it natural to reason about network partitions (temporary, intermittent, or permanent link failures leading to message loss).

Replication lag is the delay between applying a change on one replica and that change being visible on others. Because only one component or the network takes a step at a time, updates cannot be applied simultaneously across replicas. There is inherent lag (fundamental to distribution) and imposed lag (from partitions and failures). Lag can break replication transparency, especially for reads on followers.

• Synchronous: an operation completes only after all replicas acknowledge the change. Pro: immediate consistency. Con: higher latency and reduced availability if any replica is slow or unreachable.
• Asynchronous: an operation completes after the initial node processes it; replication happens in the background. Pro: low latency and higher availability. Con: replicas can be stale.
• Quorum (hybrid): wait for acknowledgments from a majority (quorum) in the foreground; replicate to others asynchronously. Balances latency, availability, and consistency.

Assuming a deterministic state machine: (1) State-based replicates the current state (or a diff), regardless of the operations that produced it. (2) Log-based replicates the sequence of operations that led to the state. In practice, log-based is often preferred because it preserves ordering and enables deterministic replays.

• Single-leader: one node accepts operations and propagates to followers—simple “chain of command,” but the leader can become a single point of failure.
• Multi-leader: multiple leaders accept operations—avoids a single bottleneck but introduces concurrent updates that can conflict.
• Leader-less: any node accepts operations—maximizes availability but requires conflict resolution.

Conflicts are resolved via strategies like last-write-wins (simple but can cause unexpected overwrites) or CRDTs (designed to converge without conflicts). Also note: reads from followers can be stale due to replication lag; read from the leader for the freshest data.