MediumLow-Level Design7 min read

Design a Simple In-Memory Key-Value Store With TTL Expiry (Mini-Redis)

Q: Design a Simple In-Memory Key-Value Store With TTL Expiry (Mini-Redis)

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Medium > **How to read this doc:** the TTL expiry claim was verified with real, measured timing — a value genuinely present immediately after `set`, and genuinely `undefined` after the real TTL had elapsed, with the internal store's own size confirmed to shrink, proving lazy self-cleanup actually happened. ## 1. The problem, restated A key-value store where each entry can optionally carry a TTL (time-to-live, in milliseconds) — once that much real time has passed since the entry was set, any further `get` for that key must return `undefined`, as if the key were never there at all. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Lazy check on access, or an active background sweep? | Lazy is the real, simpler, more common minimal approach — an active sweep adds real complexity (a timer, cleanup scheduling) for a benefit (proactively

1.0k views

88 of 154

The problem

Problem, as an interviewer would state it: "Build a minimal in-memory key-value store supporting set(key, value, ttlMs), get(key), and delete(key) — a key should genuinely become inaccessible once its TTL expires, like a simplified real Redis."

Examples:

Code

store.set("session:1", "alice", 5000);
store.get("session:1"); // "alice" -- before 5s
// ... after 5s ...
store.get("session:1"); // undefined -- genuinely expired

Clarifying questions expected:

Should expiry be checked LAZILY (only on access) or actively (a background sweep on a timer)?
What happens to a key with NO TTL specified — does it expire eventually, or persist forever?
Should a genuinely expired entry be removed from internal storage immediately, or just made inaccessible?

Code / implementation expected: Yes — real, direct proof with a real, measured 50ms TTL: the value present before expiry, genuinely gone after, with the internal store confirmed to self-clean the expired entry.

system-design
cache
ttl

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Medium

How to read this doc: the TTL expiry claim was verified with real, measured timing — a value genuinely present immediately after set, and genuinely undefined after the real TTL had elapsed, with the internal store's own size confirmed to shrink, proving lazy self-cleanup actually happened.

1. The problem, restated

A key-value store where each entry can optionally carry a TTL (time-to-live, in milliseconds) — once that much real time has passed since the entry was set, any further get for that key must return undefined, as if the key were never there at all.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Lazy check on access, or an active background sweep?	Lazy is the real, simpler, more common minimal appro

The solution is hidden so you can try first

7 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: a value is present before a real TTL elapses and genuinely undefined after, with the internal store confirmed to self-clean

Practice

Discussion

Other approaches, follow-ups and how it went in real interviews.

No comments yet. Share how you would answer it.

Question 88 of 154 in JavaScript coding

Keep your momentum going.

Mark this question solved to track your progress, then take the next one while it is fresh.

All JavaScript coding questions

Up nextMedium→

Implement Promise.all() from scratch

Continue