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

SeniorPrefer not to say

May 2026

Summary

System design round at OpenAI for a software engineer role. One meaty question about building a key-value store with crash recovery, which sounds straightforward until you actually have to talk through all the moving parts under pressure.

Questions Asked (1)

Design an in-memory key-value store with get, put, and delete operations. Every write must be persisted to a write-ahead log so the store can recover its state after a crash or restart. Walk through your log format, how you handle appends, fsync behavior, and optionally how you'd compact the log over time.

System DesignTechnical Trade-offs

Author's notes

I started with the happy path, get/put/delete backed by a hashmap, and that part was fine.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (durability, consistency, performance) and then present a high-level design of the in-memory store with a write-ahead log (WAL). Walk through the WAL format, append and fsync strategy, recovery process, and optional compaction, emphasizing trade-offs between durability and performance.

Pro tip: Demonstrate awareness of real-world systems by referencing how databases like PostgreSQL or RocksDB handle WAL and fsync batching. Discuss how you would benchmark and tune fsync frequency to balance durability and throughput.

1. Clarify Requirements and Assumptions

Ask about expected workload (read/write ratio, key/value sizes), durability guarantees (e.g., fsync on every write vs. periodic), and recovery time objectives. State assumptions clearly.

2. Design the In-Memory Store

Propose a simple hash map or concurrent map for the in-memory index. Discuss thread-safety and concurrency control (e.g., locks, sharding) for get, put, delete operations.

3. Define the WAL Format and Append Protocol

Specify a binary log format with records containing operation type, key, value, and checksum. Describe how appends are buffered and written sequentially, and how you handle partial writes.

4. Explain fsync Behavior and Durability Trade-offs

Discuss when to call fsync (e.g., after each write, group commit, or periodic). Explain the trade-off between durability and latency/throughput, and how to implement configurable durability levels.

5. Describe Recovery and Optional Compaction

Outline the recovery process: replay the WAL from the last checkpoint, applying operations to rebuild the in-memory state. Optionally, explain log compaction (e.g., snapshotting and truncating old log segments) to bound recovery time and disk usage.

Key Points to Mention

WAL record format: include operation type, key, value, checksum, and possibly sequence number or timestamp.
Append strategy: use buffered writes and batch fsyncs to improve throughput while maintaining durability.
fsync trade-offs: fsync on every write ensures durability but limits performance; group commit or periodic fsync can improve throughput at the cost of potential data loss window.
Recovery: replay WAL from last checkpoint, handle torn writes via checksums, and rebuild in-memory index.
Compaction: periodically snapshot the in-memory state and truncate the log to avoid unbounded growth and reduce recovery time.
Concurrency: ensure thread-safe operations and consistent WAL ordering, possibly using a single writer or log sequence numbers.

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