In this lesson, you will learn how to balance write durability and system availability by configuring replication factors.
When operating a distributed database, you are rarely writing to a single server. To ensure your data survives hardware failure, you replicate it across multiple nodes. The "Replication Factor" (RF) defines how many copies of your data exist across the cluster.
The Balancing Act
The trade-off between durability and availability is governed by how many nodes must confirm a write before the database acknowledges it as a success.
- High Durability (Synchronous/Strict Consistency): You require a high number of nodes to acknowledge a write. If your RF is 3, you might require a write quorum (
W=3) to confirm the data is stored on all replicas. While this ensures no data loss, it kills availability: if one node goes offline, your write operation fails because you can no longer reach the required quorum. - High Availability (Asynchronous/Eventual Consistency): You require fewer nodes to acknowledge the write (e.g.,
W=1). The system returns a "success" almost instantly, even if the data hasn't reached other replicas yet. This keeps your application responsive even if parts of your cluster are struggling, but you risk data loss if the single node holding that data fails before replicating it.
Practical Configuration
Consider a configuration where you have an RF of 3. You can tune your consistency levels using the standard quorum math (R + W > RF, where R is read nodes and W is write nodes):
-- Scenario: High Availability focus
-- W=1 ensures low latency, but risks stale reads or durability issues
SET consistency_write = 'ONE';
-- Scenario: Strong Durability focus
-- W=3 ensures all nodes have the data, but risks downtime if a node fails
SET consistency_write = 'ALL';
If you set W=1, your system remains highly available during network partitions or node crashes, but you sacrifice the guarantee that the data is durably stored. Conversely, setting W=RF guarantees that your data is safe across the cluster, but turns your entire system into a "fragile" one: if a single node hangs, your writes stop.
Key Takeaway: To optimize for availability, use lower write quorums to prioritize latency and uptime; to optimize for durability, use higher write quorums to ensure data is safely replicated before confirming success.