Design a Versioned KV Store with Time Travel

PUT, GET, and DELETE on a distributed store reads like a warm-up, and then the versioning clause turns it into the real question: a global commit order, point-in-time reads, and strong consistency. A client must be able to ask both "what is this key now" and "what was this key as of 9am last Tuesday," and get an exact answer. Meanwhile a hundred nodes serve millions of keys and writes never stop. The requirement that a read can travel backward in time rules out the obvious design where a key maps to one current value that each write overwrites. Once you have to answer the past, you can never throw it away on write.

So the spine of the answer is multi-versioning over immutable data. A PUT does not mutate a key in place; it appends a new version of that key, stamped with a commit order, and the old version stays exactly where it was. A GET with no timestamp returns the newest version. A GET as of a past time returns the newest version that committed at or before that time. A DELETE writes a tombstone version and erases nothing; the current value is just the latest point on a timeline the store keeps for every key. That is the same machinery Snowflake's Time Travel runs on, and naming it is half the round.

The Snowflake angle

Lead with distributed, multi-versioned, and time-travel, because that is what separates this from the single-box version of the question. A durable KV store on one node is a write-ahead log, periodic snapshots, and a crash-replay story, where the whole game is recovering the latest state after a process dies. This prompt is a different animal. Here the value of the system is that it keeps the past on purpose, across replicas, under a global version order, and serves a consistent snapshot to every reader. The hard parts live elsewhere. How does a point-in-time read find the right version? How does snapshot isolation give each transaction a stable view while writes pour in?