In-Memory Database / KV Store with Transactions

Question

Implement an in-memory key-value store that supports transactions. Core operations: set(key, field, value), get(key, field), delete(key, field). Transaction operations: begin/start a transaction, commit, and rollback. The key constraint is nested transaction semantics: a begin inside an active transaction creates an inner transaction; reads within any transaction must reflect writes made in that same transaction (read-your-write isolation); and outer-transaction rollback must also discard inner commits. Observed variants add TTL expiration and backup/restore on top of the transactional core. This is xAI's most-reported coding question (9 reports across a year), typically run in a CodeSignal-style staged format where requirements arrive level by level.

AceOffer · Accepted Answer

Implement an in-memory key-value store that supports transactions. Core operations: set(key, field, value), get(key, field), delete(key, field). Transaction operations: begin/start a transaction, commit, and rollback. The key constraint is nested transaction semantics: a begin inside an active transaction creates an inner transaction; reads within any transaction must reflect writes made in that same transaction (read-your-write isolation); and outer-transaction rollback must also discard inner commits. Observed variants add TTL expiration and backup/restore on top of the transactional core. This is xAI's most-reported coding question (9 reports across a year), typically run in a CodeSignal-style staged format where requirements arrive level by level.

Reported follow-ups:
1. How would you productionize this solution? (when: after basic implementation is working)
2. If the outer transaction rolls back after inner transactions have committed, what happens to those inner commits? (when: when nested transactions are introduced)
3. Can a transaction read its own uncommitted writes? (when: candidate asks about read semantics inside a transaction)
4. What is the practical difference between nested transactions with cascading rollback versus flattening all writes into a single transaction? (when: after nested transactions are implemented)
5. How do you handle TTL expiration on backup and restore? (when: TTL/versioned variant)

**Alternative approaches:** Copy-on-write snapshot per transaction (take a full snapshot at each begin — simple to reason about but O(N) memory per transaction); Undo log / undo buffer (record the previous value of each key before overwriting; on rollback, replay the undo log in reverse — O(writes) memory, the production-grade answer).

In-Memory Database / KV Store with Transactions

Problem Overview

Follow-up Arc

Approach Trade-offs

Practice

Approach	Notes
Copy-on-write snapshot per transaction	take a full snapshot at each begin — simple to reason about but O(N) memory per transaction
Undo log / undo buffer	record the previous value of each key before overwriting; on rollback, replay the undo log in reverse — O(writes) memory, the production-grade answer).