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

SeniorPrefer not to say

Apr 2026

Summary

Infrastructure round at OpenAI focused almost entirely on one deep system design problem. The question looked contained but kept expanding the longer we talked.

Questions Asked (1)

Design an in-memory key-value store that can recover its full state after a crash or disconnect, using a write-ahead log. Cover the on-disk log format, durability guarantees on put and delete operations, replay logic on startup, and how you'd handle partial or torn writes. Bonus: periodic snapshotting and log truncation.

System DesignTechnical Trade-offsAlgorithms & Data Structures

Author's notes

I started with the happy path and that was a mistake.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (durability level, performance, data size) and then walk through the design in layers: log format, write path, recovery, and snapshotting. Emphasize trade-offs (e.g., fsync frequency vs. throughput) and how you handle partial writes with checksums and length-prefixing.

Pro tip: Mention that you'd use a checksum (e.g., CRC32) per record and treat any record with a bad checksum as the end of the log, since a torn write can only occur at the tail. This shows practical experience with real-world WAL implementations.

1. Clarify requirements and assumptions

Ask about durability guarantees (e.g., must every acknowledged write survive a crash?), expected throughput, data size, and whether deletes are tombstones or physical removals. State your assumptions clearly.

2. Design the log format

Define a record structure with a length prefix, checksum, operation type (PUT/DELETE), key, value, and optional sequence number. Explain that length-prefixing allows skipping corrupt records and checksums detect torn writes.

3. Describe the write path and durability

Explain that on PUT/DELETE, you append the record to the log and optionally fsync before acknowledging. Discuss trade-offs: fsync every write (durable but slow) vs. group commit or periodic fsync (faster but may lose recent writes).

4. Explain recovery and replay logic

On startup, read the log sequentially, validate each record's checksum, and apply valid operations to rebuild the in-memory map. Stop at the first invalid record (torn write) and truncate the log there.

5. Cover snapshotting and log truncation (bonus)

Periodically write a snapshot of the in-memory state to a new file, then truncate the log. On recovery, load the latest snapshot and replay only subsequent log records. Discuss atomic snapshot creation (write to temp, fsync, rename).

Key Points to Mention

Record format: length prefix, checksum (e.g., CRC32), operation type, key, value, and optional sequence number.
Durability: fsync on every write vs. group commit; acknowledge only after fsync for strong durability.
Torn writes: detect via checksum mismatch or incomplete length; treat as end of log and truncate.
Replay: sequential scan, validate checksums, apply operations in order; idempotent operations (e.g., PUT overwrites, DELETE tombstones).
Snapshotting: periodic full state dump to a new file, atomic rename, then truncate log; recovery loads snapshot + replays tail.
Trade-offs: performance vs. durability, log size vs. snapshot frequency, complexity of concurrency during snapshot.

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