solidcodersolidcoder
Explore Courses
solidcodersolidcoder

Practical courses for software engineering interviews — no gatekeeping, no fluff.

Company-wise Questions

  • Flipkart Machine Coding Questions

Machine Coding Tutorial

  • Machine Coding Tutorial

Explore

  • Courses
  • About
  • Privacy Policy
  • Terms

© 2026 solidcoder · Practical courses for software engineering interviews.

Built for the AI era — learn by doing.

Home/Machine Coding/Machine coding Tutorial/Design an In-Memory Key-Value Store
Chapters — Machine coding Tutorial▾

Design an In-Memory Key-Value Store

Machine Coding·Machine Coding Questions·5 min read·Sep 11, 2026

Build a thread-safe in-memory key-value store with structured values, attribute-based search, type validation, and basic CRUD operations.

Asked inCREDHashiCorpFamPay

Design and implement an in-memory key-value store similar to a simplified version of Redis.

The store maintains key-value pairs where each key is a string and its value is a structured object containing multiple attributes.

For example:

"course_101": {
    "name": "System Design",
    "price": 1499.00,
    "published": true,
    "duration": 45
}

The system should support storing, retrieving, deleting, listing, and searching entries while maintaining thread safety and consistent attribute data types.

What the round tests

This one tests whether you can model a Redis-like attribute store cleanly — structured values with a global type registry, CRUD with exact output contracts, and thread-safe search indexing that stays correct under concurrent access.

Objective

The primary objective is to design and implement a thread-safe, in-memory key-value store that supports string keys, typed structured values (String / Integer / Double / Boolean), type-validated put, get, delete, keys, and attribute-based search — with strict output rules and concurrent correctness.

Functional Requirements

Three tiers of scope

Requirements are split into three tiers so you know what to prioritize under time pressure: build first, guard invariants strictly, and handle I/O and edge cases correctly.

Part 1 — Basic Requirements

Core functionality you must build and get working first.

1. In-Memory Storage

No persistence

The complete data store exists in memory. No database or file-system persistence — focus on modelling, type registry, and thread-safe operations.

2. Keys

Key rules
Rule
Detail
Unique string
Every entry has a unique string key (e.g., course_101, product_501).

3. Structured Values

Value shape
Field
Detail
Attribute name
Must be a string.
Attribute types
String, Integer, Double, or Boolean.

Example:

"product_501": {
    "name": "Mechanical Keyboard",
    "price": 2499.00,
    "stock": 120,
    "available": true
}

4. Thread Safety

Concurrency requirement
Rule
Detail
Concurrent ops
get, put, delete, search must be safe when called by multiple threads at once.

Part 2 — Core Operations

1. get(String key)

get contract
Case
Behavior
Found
Return the complete value object (attributes as key-value pairs).
Not found
Return null — driver prints: No entry found for <key>.
get("product_501") → name: Mechanical Keyboard, price: 2499.00, stock: 120, available: true

2. put(String key, List<Pair<String, String>> attributes)

put contract
Rule
Detail
Insert
Add a new key with its attributes.
Replace
If key already exists, completely replace its previous value.
Type check
Reject if any attribute violates the global type registry — driver prints Data Type Error.

Example:

put product_501 name Mechanical-Keyboard price 2499.00 stock 120 available true

3. delete(String key)

Remove the specified key and its value. If the key does not exist, no output is required.

4. keys()

keys contract
Rule
Detail
Returns
All keys currently present in the store.
Order
Sorted order.

5. search(String attributeKey, String attributeValue)

search contract
Rule
Detail
Match
Return all keys whose object contains the attribute with the given value.
Order
Sorted order.
Example
search available true → all keys where available = true.

Part 3 — Validations, Representation & I/O

1. Attribute Type Validation

Type registry (global)
Rule
Detail
First occurrence wins
An attribute's type is fixed by its first appearance in the store.
Scope
Validation applies across the entire store, not per entry.
On violation
Reject the put — driver prints Data Type Error.

Example — stock first seen as integer:

stock = 100        → type = Integer
stock = 250        → valid
stock = 250.50     → Data Type Error (double vs integer)

Similarly:

available = true   → type = Boolean
available = 1      → Data Type Error
Invalid puts

Type validation is global — do not store the entry if any attribute fails. The established type map remains unchanged on error.

2. Object Representation

toString rule
Rule
Detail
Value object
Override toString() to render as comma-separated key-value pairs.
Example
name: Mechanical Keyboard, price: 2499.00, stock: 120, available: true
Separation
Store methods must not print — driver/main handles all I/O.

3. Input Format

Driver loop
Rule
Detail
Loop
Process commands one line at a time until exit.
Constraint
Attribute names and values contain no spaces.
Supported commands
Command
Format
get
get <key>
put
put <key> <attrKey1> <attrVal1> <attrKey2> <attrVal2> ...
delete
delete <key>
search
search <attributeKey> <attributeValue>
keys
keys
exit
exit

4. Output Rules

Output contracts
Command
Output
get (found)
name: Mechanical Keyboard, price: 2499.00, stock: 120, available: true
get (missing)
No entry found for <key>
put (ok)
No output.
put (type error)
Data Type Error
delete
No output.
search / keys
Comma-separated sorted keys — e.g., product_101,product_205,product_501

Example Usage: Full Walkthrough

Here's how a sample session runs end-to-end — each command with its immediate output, using varied entries so every case is distinct (like Parking Lot's car → bike → truck flow).

1. Create entries (put — no output on success)

> put product_101 name Wireless-Mouse price 899.00 stock 50 available true
> put course_101 name System-Design price 1499.00 duration 45 published true
> put product_205 name USB-C-Hub price 1499.00 stock 30 available true

2. Get & sorted keys

> get product_101
name: Wireless-Mouse, price: 899.00, stock: 50, available: true

> keys
course_101,product_101,product_205

> search available true
product_101,product_205

Covers String (name), Double (price 899.00), Integer (stock 50), and Boolean (available true) in one round.

3. Search by different attributes

> search stock 30
product_205

> search duration 45
course_101

> search published true
course_101

Each attribute pulls a different subset — not just available — and results stay sorted.

4. Type validation — Data Type Error (Double vs Integer)

price was first seen as Double (899.00 on product_101), so an Integer must be rejected and the old entry kept.

> put product_501 name Laptop-Stand price 1999 stock 15 available false
Data Type Error

> get product_501
No entry found for product_501

> put product_501 name Laptop-Stand price 1999.00 stock 15 available false
> get product_501
name: Laptop-Stand, price: 1999.00, stock: 15, available: false
Global registry

Type is fixed on first occurrence across the entire store. A bad put stores nothing and the registry stays unchanged — next retry with 1999.00 (Double) succeeds.

5. Replace, delete, and missing key

put on an existing key completely replaces it; delete is silent.

> put product_101 name Wireless-Mouse price 999.00 stock 75 available true
> get product_101
name: Wireless-Mouse, price: 999.00, stock: 75, available: true

> delete course_101

> get course_101
No entry found for course_101

> keys
product_101,product_205,product_501

6. Search after mutation

> search price 999.00
product_101

> search available true
product_101,product_205

> search available false
product_501
Result

One walkthrough hits all contracts — typed puts with replacement, sorted keys, filtered search, global Data Type Error guard, and missing-key handling — while staying thread-safe for concurrent get/put/delete/search.

What They Looked For

Evaluation criteria
Criterion
What's assessed
Demoable & correct
All CRUD and search I/O matches the output contracts.
Data modelling
Key, structured value, and type registry are clean entities.
Thread safety
Concurrent collections / synchronization guard shared state.
Type validation
Global attribute type map enforced consistently on every put.
Clean API
Store never prints — driver owns I/O; methods are testable.
Extensibility
New attribute types or operations slot in without rewrite.
Up next8/8
Part 2 · Machine Coding Questions
←
← Prev Chapter
Message Queue
5 min
Next Chapter →
Ecommerce Loyalty Program
5 min · continue reading
→
This month's launch price
₹30,000₹3,000SOLID50 — 50% OFF

3 years access · 40+ lessons · AI assisted coding

Enroll Now →

Use code SOLID50 at checkout

On this page
  • Objective
  • Functional Requirements
    • Part 1 — Basic Requirements
    • Part 2 — Core Operations
    • Part 3 — Validations, Representation & I/O
  • Example Usage: Full Walkthrough
    • 1. Create entries (put — no output on success)
    • 2. Get & sorted keys
    • 3. Search by different attributes
    • 4. Type validation — Data Type Error (Double vs Integer)
    • 5. Replace, delete, and missing key
    • 6. Search after mutation
  • What They Looked For