A distributed database uses hinted handoff. Node B (the intended replica) is temporarily unreachable, so Node C accepts a write with a hint. A client immediately issues a read for that value, and the request is routed to Node B (which has just come back online). What does the client most likely observe?
AThe latest written value, because hinted handoff guarantees the write is applied before Node B accepts reads
BA stale or missing value, because the hint may still be queued on Node C and not yet replayed to Node B
CAn error, because Node B must fully complete hint replay before it can serve reads
DThe latest value, because hinted handoff replicates writes synchronously to the intended replica
Hinted handoff is an eventual consistency mechanism. The hint sits on Node C until Node B recovers and C forwards it asynchronously. There is no guarantee that the replay has completed before a subsequent read hits Node B. A client reading immediately after a hinted write may observe a stale value because the intended replica hasn't received the write yet. This is the key limitation: write availability is preserved, but you get eventual consistency, not read-your-writes or strong consistency.
Question 2 Multiple Choice
A node has been accumulating hints for a failed replica for two weeks with no sign of recovery. What should the system do with these hints?
ARetain all hints indefinitely — discarding them means permanent data loss
BDrop them after the configured retention window and rely on anti-entropy or read repair to reconcile any divergence
CAutomatically promote the hinting node to become the permanent new replica for that data
DCompress and archive the hints to cold storage for potential future manual recovery
Hinted handoff is designed for *transient* failures. A node absent for weeks is likely permanently gone. Retaining hints indefinitely consumes disk space on the hinting node and can overwhelm a recovering node with a flood of replayed writes. Production systems (Cassandra, Dynamo) set a maximum hint retention window (often a few hours). After that window, undelivered hints are dropped, and other mechanisms — anti-entropy reconciliation, read repair, or manual bootstrapping — handle the divergence. Relying on hints for long-term data durability is a design error.
Question 3 True / False
Hinted handoff is designed specifically to handle *transient* node failures; for nodes that are permanently lost, other consistency repair mechanisms must be used.
TTrue
FFalse
Answer: True
The entire mechanism assumes the intended node will return and accept the replayed write. If the node never recovers, hints accumulate, consume resources, and are eventually dropped without delivery. Permanent failures require different solutions: anti-entropy (comparing data between replicas via Merkle trees to find and fix divergence) or manual bootstrap/repair procedures. Hinted handoff is a tactical tool for short outages, not a durability guarantee.
Question 4 True / False
A successful hinted-handoff write guarantees that any subsequent read from the intended replica will return the latest written value.
TTrue
FFalse
Answer: False
This is the most important misconception about hinted handoff. The write succeeds from the client's perspective, but the data lives on the hinting node as a hint — not yet on the intended replica. A read that reaches the intended replica before the hint is replayed will return a stale value. Hinted handoff provides write availability and eventual consistency, not read-after-write consistency or strong consistency. Applications requiring the latter must use quorum reads or other stronger consistency protocols.
Question 5 Short Answer
Why does a successful hinted-handoff write not guarantee that a subsequent read from the intended replica returns the latest value, and what consistency model does hinted handoff provide?
Think about your answer, then reveal below.
Model answer: Hinted handoff stores the write as a hint on a surrogate node, not on the intended replica. The intended replica only receives the write when it recovers and the hinting node replays the hint — an asynchronous process that may take seconds to minutes. A read issued before hint replay completes will miss the write. This means hinted handoff provides eventual consistency: the write will eventually reach all replicas, but there is no bound on when, and reads in the interim may return stale data.
The key insight is that write availability and read consistency are separate properties. Hinted handoff maximizes write availability (writes succeed even when replicas are down) at the cost of read consistency (reads may miss recent writes during the hint-replay window). Systems that need both must combine hinted handoff with quorum-based reads or other mechanisms that account for in-flight hints.