Home/Low-level design/Transactional Key-Value Store

Transactional Key-Value Store

Nested transactions and rollback boundaries

Nested transactions create a stack of visible views. An inner commit merges into its immediate parent, so an outer rollback must still undo that commit. Treating every commit as durable base storage breaks nesting.

go
view := map[string]string{"empty": ""}
value, present := view["empty"]
fmt.Println(value, present) // empty string is present

A copied-map prototype makes ownership easy to reason about at O(number of keys) per begin. Overlay maps with deletion markers can reduce copying but make lookups and merges more subtle. Deletion must hide a parent key rather than falling through to it. Return snapshots must not expose any live frame. This exercise defines nesting behavior, without concurrency or durability claims.

Go models this service with a struct and pointer-receiver methods. Constructor functions return a pointer; validation failures return errors rather than panicking. Scalars in snapshot structs are copied by value. Maps, slices, and optional pointers still require detached copies when crossing the service boundary. Go maps do not have key iteration order; use ordered slices for ranked results. There are no threads, persistence, wall-clock reads, or external side effects in this exercise.

Put it into practice

Implement the exercise in a full-screen workspace, then run its tests.

Open practice
Next lessonIn-Memory Database