Multi-DC Cassandra: Consistency, Replication, and Surviving a Datacenter Failure
Deploying a database across multiple cloud regions is the ultimate test of distributed systems engineering. Apache Cassandra is one of the few databases mathematically proven to survive the total loss of a datacenter without taking down the application.
However, if your client drivers and consistency levels are misconfigured, a regional outage in AWS us-east-1 will instantly cascade and take down your healthy us-west-2 environment.
Situation
In 2024, the 54-node Cassandra 4.1 cluster was deployed active-active across two AWS Regions: 27 nodes in us-east-1 and 27 nodes in us-west-2. The dataset was approximately 50 TB, fully replicated to both coasts.
When a major AWS regional network partition isolated us-east-1, the applications in us-west-2 should have continued operating normally. Instead, HTTP 500 errors spiked across the West Coast. Application driver threads blocked indefinitely on cross-region coordinator requests, VPC peering bandwidth saturated, and the entire platform ground to a halt.
The Problem
The failure was not in Cassandra’s architecture; it was in the application’s consistency configuration.
When you create a keyspace for multi-region replication, you use NetworkTopologyStrategy:
CREATE KEYSPACE production WITH replication = {
'class': 'NetworkTopologyStrategy',
'us-east-1': 3,
'us-west-2': 3
};
This guarantees three copies of the data exist on the East coast, and three copies exist on the West coast.
However, the application was performing writes using the QUORUM consistency level. In a 6-replica cluster, QUORUM requires acknowledgements from 4 nodes (6 / 2 + 1 = 4).
This meant every single write executed in us-west-2 required a synchronous network trip across the country to wait for an acknowledgement from at least one node in us-east-1. When us-east-1 went offline, us-west-2 could only gather 3 local acknowledgements. The writes failed. The database protected consistency at the cost of total system availability.
Furthermore, the DataStax Java driver was not configured with local datacenter affinity. The load balancer was sending West Coast application queries directly to East Coast Cassandra coordinators, causing massive latency overhead even when the network was healthy.
The Active-Active Multi-Region Architecture
To survive a regional failure, you must decouple the geographic regions using asynchronous replication boundaries.
flowchart TD
App[West Coast Application] -->|LOCAL_QUORUM| Coord(West Coast Coordinator)
subgraph "AWS us-west-2 (Local DC)"
Coord -->|Write| N1[Node 1]
Coord -->|Write| N2[Node 2]
Coord -->|Write| N3[Node 3]
end
Coord -.->|Async Replication| EastCoord(East Coast Coordinator)
subgraph "AWS us-east-1 (Remote DC)"
EastCoord -->|Write| N4[Node 4]
EastCoord -->|Write| N5[Node 5]
end
%% Hinted Handoff
EastCoord -.->|Network Partition| Failed[Nodes Unreachable]
Coord -.->|Store Hint| Hint[(Hinted Handoff — Local Disk)]
1. Enforcing LOCAL_QUORUM
The pattern standardizes all application profiles to use LOCAL_QUORUM for both reads and writes.
LOCAL_QUORUM fundamentally changes the physics of the query. It keeps the acknowledgement requirement strictly within the coordinator’s local datacenter. The West Coast coordinator requires 2 acknowledgements out of the 3 West Coast replicas to return success to the application. It still asynchronously replicates the mutation to the East Coast, but it does not wait for the East Coast to acknowledge. If the East Coast goes offline, the West Coast application never notices.
2. Driver Datacenter Affinity
We reconfigured the DataStax Java Driver’s local-datacenter affinity (basic.load-balancing-policy.local-datacenter in the 4.x driver — the successor to the legacy DCAwareRoundRobinPolicy from the 2.x/3.x driver series). This forced West Coast microservices to only open connections and coordinate queries with West Coast Cassandra nodes, eliminating cross-country VPC traffic from the hot path.
3. Tuning Hinted Handoff
When us-east-1 goes offline, the us-west-2 nodes store the missed writes locally on disk as “hints”. When the network recovers, they stream these hints to the East Coast to heal the data. The standard approach tunes max_hint_window_in_ms to 3 hours, ensuring the cluster could safely buffer a regional disconnect without dropping mutations.
In Practice
This architecture is proven by adopting Chaos Engineering. The documented pattern uses AWS Fault Injection Simulator to intentionally drop all packets across the VPC Peering link, effectively simulating a full regional partition.
Because the applications were using LOCAL_QUORUM and local-datacenter driver affinity, p99 latency in us-west-2 remained perfectly flat at 5ms. The nodes buffered the hints locally. When we restored the peering link 30 minutes later, nodetool statushandoff showed the hints streaming across the country, silently reconciling the data.
Where It Breaks
| Design Choice | Tradeoff | Mitigation |
|---|---|---|
Using EACH_QUORUM | Forces synchronous writes to both datacenters. Ensures perfect global consistency but makes the cluster vulnerable to a single region failure. | Never use EACH_QUORUM unless regulatory compliance mandates synchronous multi-region writes. |
| Disabling Hints | If you disable hinted handoff to save disk space, a 10-minute network blip will require a multi-terabyte cross-region repair. | Keep hints enabled and monitor the HintsDispatchExecutor in nodetool tpstats. |
| Massive Regional Outages | If a region is down for 24 hours, hint buffers will overflow and drop writes. | Run a full cross-DC nodetool repair (via Cassandra Reaper) immediately after the region recovers. |
Modern Cassandra Context: Multi-Region Database Cost Economics
Deploying Active-Active Cassandra across AWS regions incurs significant Inter-Region VPC Peering bandwidth costs due to constant asynchronous replication. However, compared to managed services like Aurora Global Database or DynamoDB Global Tables, running open-source Cassandra 5.0 across multiple regions provides vastly superior write availability. Cassandra’s masterless architecture ensures that both regions can accept writes simultaneously without the latency penalties of cross-region primary-node failovers.
What to Do Next
- Problem: Using
QUORUMin a multi-region cluster creates synchronous cross-country dependencies, turning a single region failure into a global outage. - Solution: Standardize on
LOCAL_QUORUMfor all reads and writes, and enforce local datacenter affinity in the client driver. - Proof:
LOCAL_QUORUMprovides local strong consistency while allowing asynchronous cross-region replication to survive VPC network partitions cleanly. - Action: Check your application driver configuration. If
basic.load-balancing-policy.local-datacenter(or your driver’s equivalent local-DC affinity setting) is not explicitly set, you are paying a massive, unnecessary latency tax.