Skip to main content
cd ../lexicon
sys/docs/lexicon/hinted-handoff.md
Lexicon

Hinted Handoff

Difficulty: Advanced
3 min read
Definition
When a database node is temporarily unreachable, hinted handoff lets another healthy node accept and hold its write on its behalf, along with a note about where it really belongs. Once the original node comes back online, the stored write is delivered to it and the temporary copy is removed. This keeps writes succeeding even during partial outages, at the cost of the data briefly living in the 'wrong' place.

In a leaderless architecture using consistent hashing, every key maps to a preference list of N nodes responsible for its replicas. During a write, the coordinator attempts to contact all N nodes but only requires W acknowledgments to satisfy the quorum. Hinted Handoff is the failure-mode escape valve: if one of the N target nodes is down or unreachable within the request timeout, the coordinator does not block or fail the write outright. Instead, it selects a healthy node outside the natural preference list, stores the replica payload there alongside a hint in local metadata indicating the original intended destination, and counts that write toward the quorum.

The hinted replica is functionally a piece of orphaned data sitting on the wrong node. It is invisible to normal read-path replica lookups on that node (reads still query the canonical preference list) and exists purely as a durability buffer. When the coordinator’s failure detector (typically gossip-based, e.g., Phi Accrual) observes the original target node rejoin the cluster, a background handoff process streams the hinted data to its rightful owner and then deletes the local hint. This is distinct from Read Repair and Anti-Entropy (Merkle-tree driven) mechanisms, which reconcile divergent replica state after the fact; hinted handoff prevents the divergence from ever being visible to a quorum read in the first place, provided the handoff completes before the outage duration exceeds any configured hint TTL.

The primary engineering tension is unbounded hint accumulation. If a node is down for an extended period (exceeding max_hint_window_in_ms in Cassandra terminology), surrounding nodes may accumulate massive volumes of hinted writes, consuming disk and eventually causing compaction/replay storms when the node returns. Most implementations enforce a hint TTL after which accumulation stops and the write is considered permanently lost from that coordinator’s perspective — requiring the eventual read-repair or full anti-entropy sync (Merkle tree comparison) to restore consistency instead. This creates a durability cliff: hinted handoff guarantees availability, not durability, and operators must tune the hint window against expected MTTR for node recovery.

  • Failure interaction: Hinted handoff assumes transient failure. On permanent node loss (disk death), hints stored elsewhere become the only surviving copy until anti-entropy repair rebuilds the replacement node.
  • Quorum implication: A write satisfied via hinted handoff counts toward W, meaning a client can receive a success ack even though zero of the N canonically correct nodes hold the data yet — a subtlety that breaks naive assumptions about read-after-write consistency if R and W overlap sets are computed against the preference list rather than actual holders.
  • Cascading load risk: Handoff replay on node rejoin is I/O and network intensive; large hint backlogs after a rolling restart are a known cause of secondary outages if throttling (rate-limited handoff streaming) isn’t enforced.