Writeの際にそのキーを担当するレプリカノードの一つが停止していた場合、Cassandraはヒント情報を稼働しているレプリカノードの一つに保存します。ヒント情報は障害中のノードに対して当該の書き込みを再実行する必要があることを示します。この機構をHinted Handoffと呼びます。あるキーに対して稼働中のレプリカノードが一つも存在せず、かつConsitencyLevel.ANYが指定されている場合、コーディネーティングノードは自ノードにヒントを保存します。
CassandraはHinted Handoffを次の目的で使用しています。
- 一時的障害により他のレプリカとの一貫性を失ったノードが稼働中のレプリカと再同期するのに必要な時間を短縮する
- 一貫性の要求が低いシステムにおいて、極めて高い書き込み可用性を提供する
ヒントそのものはConsistencyLevel ONE、QUORUM、ALL条件判定の際にカウントされません。簡単な例として、2つのノード、AとBから構成されるクラスタを考えます。レプリケーションファクタは1とします（それぞれのキーは一つのノードのみに格納されます）。ノードAが停止している間に、ノードAに格納されるべきキーKをConsistencyLevel.ONEで書き込むとします。この場合、書き込みは失敗します。APIページで次のように書かれていたことを思い出して下さい。
”Wを書き込み時にブロックするノード数、Rを読み出し時にブロックするノード数とすると、W＋R＞ReplicationFactorが満たされていれば強い一貫性を保証できます。言い換えると、Read操作は常に最新のWriteデータを返します。”
もしヒントをノードBに書いたことをもってそのWrite操作を完了と見なすと、どのようなConsistencyLevelを使用してもそのデータを読み出す方法はありません：ノードAが復帰し、ノードBがデータをAに転送するまでは。従来は最も低いConsistencyLevel、ZEROのみがこのようなWriteを許容できました。Cassandra 0.6ではConsistencyLevel.ANYが追加されています。ConsistencyLevel.ANYのWriteは次のようなことを意味します。
”例え直ちに読み出せないヒント情報であっても、とにかく「どこかに」書き込めたらWriteを完了する”