Thread-Safe Cache

Phase 1: Requirements & Use Cases

Interviewer: "Design a thread-safe in-memory cache."

Candidate: "Let me make sure I understand the scope. We're building a generic in-memory cache that multiple threads can read from and write to concurrently — with support for cache eviction. We're NOT designing a distributed cache like Redis; this is a single-process, in-memory cache at the class level. Does that match?"

Interviewer: "Yes. What actors and use cases do you see?"

Candidate: "The actors are reader threads fetching cached values and writer threads inserting or updating entries. The core use cases are:

1. get(key) — retrieve a value by key, return null on miss
2. put(key, value) — insert or update an entry
3. evict(key) — explicitly remove an entry
4. auto-eviction — remove entries when capacity is exceeded (LRU policy)
5. TTL expiry — optionally expire entries after a set time
6. clear() — remove all entries"

Interviewer: "What about TTL-based expiration? Is that in scope?"

Candidate: "I'd scope it as an optional extension. The core design will handle capacity-based eviction (LRU) first — TTL can be layered on with a lazy expiry check on get or a background sweeper. Getting the concurrency model right is the harder problem here."

WHY: TTL introduces a time dimension and potentially a background thread, which complicates the concurrency model. Nailing LRU eviction with correct locking demonstrates the core challenge.

Interviewer: "What concurrency assumptions are you making?"

Candidate: "I'm assuming high read-to-write ratio — caches are typically read-heavy. That shapes my locking strategy. I'll assume we need…