Consistency Repair Mechanism

1. Read Repair

During a read, the coordinator that is just the node connects and services the client, contacts a number of nodes as specified by the consistency level for data and the fastest replicas will return the data for a consistency check by in-memory comparison. As it is not a dedicated node, Cassandra lacks a single point of failure. It also checks all the remaining replicas in the background. If a replica is found to be inconsistent, the coordinator will issue an update to bring back the consistency. 

2. Hinted Handoff

Hinted handoff aims at reducing the time to restore a failed node when rejoining the cluster. It ensures absolute write availability by sacrificing a bit of read consistency. If a replica is down at the time a write occurs, another healthy replica stores a hint. Even worse, if all the relevant replicas are down, the coordinator stores the hint locally. The hint basically contains the location of the failed replica, the affected row key, and the actual data that is being written. When a node responsible for the token range is up again, the hint will be handed off to resume the write. As such, the update cannot be read before a complete handoff, leading to inconsistent reads.

3. Anti-entropy
A replica synchronization mechanism to ensure up-to-date data on all nodes and is run by the administrators manually