How do per-cell timestamps work in a wide-column store, and how does the store decide which value a read returns when a cell was written twice?

## A timestamp on every cell In a wide-column store the smallest unit is a **cell**: a key, a column and a **timestamp**, holding a value. The timestamp is normally a 64-bit number of micro- or milliseconds, assigned by the server when the write arrives, though most stores let a client supply its own. Writes are **never updates in place**. Writing the same column again adds another cell with a new timestamp; the older one is still on disk until background merging removes it. ## Resolving a read When a read finds several cells for the same key and column — in memory, in different files, or on different replicas — the rule is simple: - the cell with the **highest timestamp** is the current value; - ties are broken by a deterministic rule of the store, so every copy picks the same winner. This is **last-write-wins by timestamp**, not by arrival order. A write that arrives late but carries a higher timestamp still wins, and one that arrives late with a lower timestamp loses. ## Keeping versions versus superseding them Stores in the family handle the older cells in one of two ways: | behaviour | what a read sees | what bounds storage | |---|---|---| | **retained versions** | newest by default; a read may ask for the last *n* versions or a time range | a per-family rule: keep *n* versions, or versions younger than an age | | **superseded values** | only the newest value | older cells are dropped when files are compacted | Retained versions make the timestamp a genuine third dimension of the data: you can store the history of a value in one cell. Where only the newest value is visible, the timestamp still matters, because it is how replicas and merges agree on the winner. ## Deletes are stamped too A delete writes a **marker** with its own timestamp that hides every cell for that key and column with an **equal or older** timestamp. So if a client later writes a value with a timestamp **earlier** than the marker, that value is invisible even though it was written after the delete in wall-clock time. How long markers are kept is a separate subject — merge-time deletion and what happens if markers are dropped too early. ## Who sets the clock Timestamps are only as good as the clocks that produce them. 1. **Server-assigned** stamps depend on server clocks; in a store where any replica can coordinate a write, clock skew between servers can reorder two close writes. 2. **Client-supplied** stamps move the problem to every client, and a client with a fast clock can make its writes win for as long as the skew lasts — or make a later correction "lose". 3. Some designs use timestamps deliberately as data, for example writing a reading with the time it was taken, so replays land in the right place. The practical rule: if two writers can touch the same cell and order matters, do not rely on timestamps to express intent. Use a conditional write, or model the history as separate cells or rows. ## Interview angle Strong answers say "every cell is stamped, highest stamp wins", distinguish retained versions from superseded values, and raise clock skew and the delete-marker interaction unprompted.