O9 · Design an In-Memory Database O9 · 设计内存数据库
Verified source经核实出处
Prompt: "Design an in-memory database." — IGotAnOffer (also Glassdoor, StaffEngPrep, PracHub). Credibility B / D (curated + interview-coach).
Scope control (critical)范围控制（关键）
Start with SET / GET / DEL + TTL + prefix scan. Evolve to persistence (AOF / snapshot), sharding, replication. Follow-ups may add GROUP BY, ORDER BY.从 SET/GET/DEL + TTL + 前缀扫描开始。演进：持久化（AOF/snapshot）、分片、复制。追问可加 GROUP BY、ORDER BY。
Core architecture核心架构
flowchart LR C[Client] --> API[KV API] API --> MEM[(Memtable)] API --> WAL[(Write-Ahead Log)] MEM --> SNAP[Snapshot]
APIAPI 设计
PUT /kv/{key} body { value, ttl_seconds? }
GET /kv/{key}
DELETE /kv/{key}
GET /scan?prefix=&limit=&cursor=Internals内部实现
- Sharding: consistent hash or modulo per shard; RWLock within a shard.分片：一致性哈希或取模；shard 内 RWLock。
- TTL: min-heap or timing wheel; background reaper + lazy delete.TTL：小根堆或 timing wheel；后台清理 + 懒删。
- Persistence: append-only WAL + periodic snapshot; recover = load snapshot + replay WAL.持久化：追加 WAL + 周期 snapshot；恢复 = 加载 snapshot + 重放 WAL。
Trade-offs权衡
- Single leader = simple consistency. Multi-replica needs replication protocol (Raft / quorum), with obvious write-latency cost.单主：一致性简单。多副本需要复制协议（Raft / quorum），写延迟代价明显。
- Read-from-replica possible but requires explicit stale-read policy.副本读可行但需明确的陈旧读策略。
How to level up the answer如何把答案做出高度
Mention Redis's actual design choices (single-threaded per shard, AOF+RDB combined, PSYNC for replication) to anchor it in production reality — interviewers love this signal.提 Redis 的真实选型（每 shard 单线程、AOF+RDB 组合、PSYNC 复制）——这是面试官喜欢的工程现实信号。