Design a versioned key-value store

Quick Overview

Design a versioned key-value store evaluates algorithm design, data structures, correctness, complexity, edge cases, and implementation details in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design a versioned key-value store

Company: Instacart

Role: Software Engineer

Category: Coding & Algorithms

Difficulty: medium

Interview Round: Onsite

Design and implement a versioned key-value store that supports set(key, value, timestamp) and get(key, timestamp) to retrieve the most recent value at or before timestamp. Discuss data structures, time/space complexity, and how to handle out-of-order timestamps, large timestamp ranges, and memory limits. Extend the API to support delete, range queries by time, and background compaction.

Overview: Design a versioned key-value store evaluates algorithm design, data structures, correctness, complexity, edge cases, and implementation details in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Instacart logo
Instacart
Aug 1, 2025
mediumSoftware EngineerOnsiteCoding & Algorithms
10
0

Design a versioned key-value store

Design and implement a versioned key-value store that supports set(key, value, timestamp) and get(key, timestamp) to retrieve the most recent value at or before timestamp. Discuss data structures, time/space complexity, and how to handle out-of-order timestamps, large timestamp ranges, and memory limits. Extend the API to support delete, range queries by time, and background compaction.

Clarifying Questions to Ask Guidance

  • Clarify input sizes, value ranges, mutability, return format, and tie-breaking.
  • State the target time and space complexity before coding.
  • Call out edge cases such as empty inputs, duplicates, invalid values, overflow, and boundary sizes.

What a Strong Answer Covers Guidance

  • A clear algorithm with the right data structures and enough pseudocode or code-level detail to implement it.
  • A correctness argument that explains why the algorithm covers all required cases.
  • Time and space complexity, plus at least one alternative approach when relevant.
  • Focused tests for normal cases, edge cases, and failure modes.

Follow-up Questions Guidance

  • How would the approach change if the input were streaming or too large for memory?
  • What invariants would you assert in production code?
  • Which tests would catch off-by-one, duplicate, or tie-breaking bugs?