Cassandra Consistency Violation: Causes and Fixes

1. Wrong Consistency Level for Your Replication Factor

I know this error is infuriating. You're running a query and boom — ConsistencyViolationException. Nine times out of ten, the problem is you're asking Cassandra to do something it physically can't. Let me explain.

Cassandra's consistency level tells the cluster how many nodes must respond for an operation to succeed. If your replication factor (RF) is 3, and you set CONSISTENCY ALL, then every single replica must be available. If one node is down, your query fails. That's the violation.

The real fix: match your consistency level to your RF realistically. Here's what I use:

• For writes: CONSISTENCY QUORUM (RF/2 + 1). With RF=3, quorum is 2 nodes. More forgiving than ALL.
• For reads: CONSISTENCY LOCAL_QUORUM if you're using multiple data centers. Keeps traffic local and avoids cross-datacenter delays.
• Only use ALL if you absolutely need every replica to respond, and you have strong monitoring. It's risky.

Check your current consistency level with:

cqlsh> CONSISTENCY;
Current consistency level is ONE.

Change it per query:

cqlsh> CONSISTENCY QUORUM;

This tripped me up the first time too. I had RF=2 and set CONSISTENCY ALL. Obviously, if one node goes, you're stuck. Drop to QUORUM in that case — you still get strong consistency with one node failure allowed.

2. Node Failures or Network Partitions

Second most common cause: a node in your cluster is down, or there's a network partition cutting off communication. Cassandra is distributed, so if a node is unreachable during a quorum read, you get this error.

Check node status first:

nodetool status

Look for nodes marked DN (down) or N/A (unknown). If you see any, that's your problem. The affected keyspace's replicas can't be reached.

Here's what to do:

1. Restart the dead node — systemctl restart cassandra on that machine. Wait 2-3 minutes for gossip to sync.
2. Run repair — once it's back up, run nodetool repair -pr on the affected keyspace. This fixes inconsistencies between replicas.
3. Check network — if nodes keep dropping, look at your firewall rules and DNS. Cassandra uses port 7000 for internode communication. Make sure it's open between all nodes.

I've seen this happen a lot after a cloud provider outage. One node goes down, and suddenly all your QUORUM reads fail. The fix isn't to change consistency — it's to get that node back up.

If you're running Cassandra 4.0 or newer, you can also check nodetool gossipinfo to see if gossip is working correctly. A node might be up but not gossiping properly.

3. Hint Handoff Failures or Tombstone Overload

Third cause is trickier. Sometimes the cluster looks healthy, but consistency still fails because of hint handoff issues or too many tombstones.

Hint handoff — when a node is down temporarily, other nodes store hints (writes) for it. If the down node takes too long to come back, hints expire (default 3 hours in Cassandra 3.x, configurable in cassandra.yaml via max_hint_window). When hints expire, those writes are lost. If you then try to read with CONSISTENCY ALL or QUORUM, the node that missed the write won't have it, and the read fails.

Fix: reduce the hint expiration window, or better, monitor node uptime. I set max_hint_window_in_ms to 3600000 (1 hour) to avoid stale hints. But the real solution is to keep nodes up.

# in cassandra.yaml
max_hint_window_in_ms: 3600000

Tombstone overload — when you delete data, Cassandra leaves tombstones. Too many tombstones during a read can cause a timeout, which looks like a consistency violation. This happens when you delete a lot of rows but don't run compaction.

Check tombstone count per table:

nodetool cfstats keyspace_name.table_name | grep -i tombstone

If you see thousands per read, run a manual compaction:

nodetool compact keyspace_name table_name

Also adjust your compaction strategy. I prefer SizeTieredCompactionStrategy for write-heavy workloads and LeveledCompactionStrategy for read-heavy ones. Switch in CQL:

ALTER TABLE keyspace_name.table_name WITH compaction = {'class': 'LeveledCompactionStrategy'};

This clears tombstones faster and prevents those timeout errors.

Quick-Reference Summary Table

Start with the consistency level check — it's the quickest fix and the most common. If that's fine, move to node health. Only dig into hints and tombstones if the first two don't work. You'll save hours this way.