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

SeniorPrefer not to say

Apr 2026

Summary

System design round at OpenAI for a software engineer role. The main problem was building an in-memory key-value store with persistence, which sounds straightforward until you get into the weeds on serialization and crash consistency.

Questions Asked (1)

Design and implement an in-memory key-value store with a persistence layer. You need four operations: set, get, shutdown, and restore. On shutdown the store flushes to bytes; on restore it rebuilds from those bytes. Walk through the medium interface, serialization format, error handling, crash consistency, performance, and how you'd test it.

System DesignTechnical Trade-offsAPI & Integrations

Author's notes

This question has a lot of surface area and I think I underestimated how deep they wanted to go on each sub-part.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and defining a clean interface with explicit error semantics, then walk through the serialization format and crash-consistency guarantees. Emphasize trade-offs (e.g., durability vs. performance) and how you'd test edge cases like partial writes and corruption.

Pro tip: Anchor your design around a write-ahead log (WAL) with checksums and atomic rename for the snapshot, and explicitly discuss how you'd handle torn writes and recovery — this shows you understand real-world persistence pitfalls beyond textbook answers.

1. Clarify requirements and define the interface

Ask about expected data size, concurrency, durability guarantees, and whether the store is embedded or networked. Define the four operations with precise signatures, return types, and error contracts (e.g., get returns optional, set returns error, shutdown/restore are idempotent).

2. Design the in-memory data structure and concurrency model

Choose a hash map for O(1) average access, discuss thread-safety (locks vs. sharding vs. lock-free), and how you'll handle concurrent set/get during shutdown. Mention memory management and potential eviction policies if needed.

3. Define the serialization format and persistence strategy

Propose a binary format (e.g., length-prefixed records with CRC32 checksums) or a structured format like Protocol Buffers. Explain how you'll write atomically (write to temp file + fsync + rename) and whether to use a WAL for incremental durability or a full snapshot on shutdown.

4. Address crash consistency and error handling

Detail how you detect and recover from partial writes, corruption, and crashes during shutdown. Discuss checksums, versioning, and recovery logic (e.g., ignore incomplete trailing records). Specify error propagation for I/O failures and how restore handles missing or incompatible files.

5. Outline performance considerations and testing plan

Analyze time/space complexity of operations and serialization overhead. Describe tests: unit tests for each operation, property-based tests for round-trip consistency, fault-injection tests for crash scenarios, and benchmarks for throughput/latency.

Key Points to Mention

Atomic file replacement via temp file + fsync + rename to avoid torn writes
Checksums (e.g., CRC32) per record or block to detect corruption
Write-ahead logging (WAL) for durability vs. full snapshot on shutdown
Concurrency control: read-write locks or sharded maps to allow concurrent gets during shutdown
Error handling: distinguish between transient I/O errors and permanent corruption; define retry and fallback behavior
Testing: fault injection (e.g., kill process mid-write), property-based round-trip tests, and performance benchmarks

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