Openai·Software Engineer·Onsite - System Design / Architecture·Senior

Senior

Jun 2026

Summary

System design round at OpenAI, one big open-ended question about building a distributed key-value store. They wanted the full picture, not just a sketch, so it went pretty deep.

Questions Asked (1)

Design a distributed key-value store. Walk through the data model and API, how you'd partition the data, your replication and consistency approach, failure handling, how you'd deal with hot keys, persistence, and how the system scales under read and write pressure.

System DesignTechnical Trade-offsData Modeling

Author's notes

This is a beast of a question and I underestimated how much they wanted me to actually commit to tradeoffs rather than just list options.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (scale, consistency, latency) and then present a high-level design covering data model, partitioning, replication, and failure handling. Dive into trade-offs for each component, and conclude by addressing hot keys, persistence, and scaling under read/write pressure.

Pro tip: Explicitly state your assumptions about scale and consistency requirements upfront; this shows you can drive a design conversation and avoid solving the wrong problem.

1. Clarify Requirements and Scope

Ask about expected scale (data size, QPS), consistency needs (strong vs eventual), latency targets, and failure tolerance. This shapes all subsequent design decisions.

2. Define Data Model and API

Propose a simple key-value interface (get, put, delete) and discuss optional features like versioning or TTL. Mention that keys are opaque strings and values are blobs.

3. Design Partitioning and Replication

Explain partitioning via consistent hashing (or range-based) and replication factor N with a coordinator-based or leaderless approach. Discuss consistency models (e.g., quorum-based) and trade-offs.

4. Address Failure Handling and Hot Keys

Describe failure detection (heartbeats, gossip), recovery (hinted handoff, read repair), and mitigation for hot keys (key splitting, caching, load balancing).

5. Cover Persistence and Scaling

Discuss storage engines (LSM trees vs B-trees), write-ahead logging, and scaling strategies (adding nodes, rebalancing, read replicas, caching layers).

Key Points to Mention

Consistent hashing for partitioning to minimize rebalancing when nodes join/leave
Quorum-based replication (e.g., N=3, W=2, R=2) to tune consistency vs latency
Vector clocks or versioning for conflict resolution in eventually consistent systems
Hot key mitigation: key salting, splitting, or dedicated caching layer
Persistence options: LSM trees (write-optimized) vs B-trees (read-optimized), and WAL for durability
Scaling under read/write pressure: read replicas, write sharding, and backpressure mechanisms

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.