Why High Availability Triggers a Consistency‑Performance Trade‑off in Distributed Databases

High availability for data services requires storing multiple copies of data, which creates consistency problems that further lead to performance issues, forming a classic trade‑off loop.

When a single server provides data services, two main problems arise: insufficient performance for all requests and risk of service loss or data loss if the server fails.

To address these, two common expansion methods are used:

Data partitioning : split data across different servers (e.g., uid % 16, consistent hashing).

Data mirroring : synchronize all servers to provide identical data services.

Data mirroring with redundancy (typically three copies) is needed for high availability, but adding more machines increases complexity, especially for cross‑server transaction consistency. The classic use case of transferring money from account A to account B illustrates a six‑step transaction that must be atomic and lock both accounts.

With partitioning, if A and B reside on different servers, a cross‑machine transaction and possible rollback are required. With mirroring, concurrent operations on the same account across different replicas must ensure consistency without conflicts.

Key concerns are disaster recovery (no data loss, failover), data consistency (transaction processing), and performance (throughput, latency). In redundant setups, data copies (replicas) are the only way to avoid data loss.

Consistency Models

Three basic consistency types are discussed:

Weak consistency : after a write, some replicas may or may not see the new value (e.g., caches, VOIP).

Eventually consistency : the new value becomes visible after some time (e.g., DNS, email, Amazon S3).

Strong consistency : any read from any replica returns the latest write instantly (e.g., file systems, RDBMS).

Weak and eventual consistency are usually achieved with asynchronous replication, offering better performance but more complex state control, while strong consistency relies on synchronous replication, simplifying logic but reducing performance.

Replication Architectures

Master‑Slave : the master handles all read/write requests; slaves replicate the master’s writes either asynchronously or synchronously. Asynchronous replication yields eventual consistency but risks data loss if the master fails before slaves catch up; synchronous replication can provide strong consistency but adds latency.

Master‑Master (Multi‑master) : multiple masters provide read‑write services, typically replicating asynchronously, leading to eventual consistency. Conflict resolution becomes challenging when the same data is modified on different masters.

Two‑Phase Commit (2PC)

2PC ensures atomicity across multiple nodes by using a coordinator that first asks all participants if they can commit (prepare phase) and then, if all agree, sends a commit command (commit phase). If any participant votes no, the coordinator issues a rollback. Timeouts and coordinator failures can block the transaction.

Three‑Phase Commit (3PC)

3PC adds an extra pre‑commit phase to avoid the blocking problem of 2PC: after the initial vote, participants lock resources only after all have agreed, then a final commit is issued. This reduces the chance of participants being left in an uncertain state.

Two Generals Problem

The classic Two Generals Problem demonstrates the impossibility of achieving reliable coordination over an unreliable communication channel, illustrating why protocols like 2PC/3PC must handle message loss and timeouts.

The discussion highlights that network timeouts, message loss, and coordinator availability are critical challenges in designing robust distributed transaction systems.