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

Senior

Apr 2026

Summary

OpenAI system design round for a software engineer role. The whole thing was one big distributed systems problem that required me to think about message propagation, deduplication, and topology inference simultaneously. Pretty intense for a single question.

Questions Asked (1)

Given a distributed cluster of machines connected in some topology, implement a receiveMessage(msg, fromMachine) function on each node so that messages propagate correctly through the network. Each node should be able to infer the total machine count and key topology properties (neighbors, reachability) purely from the messages it observes. Focus on the receive-handling logic, message format, idempotency, deduplication of repeated messages, and how topology information accumulates over time.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

I started with flooding and immediately got asked how I'd prevent cycles.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the problem constraints and assumptions, then design a message format that includes a unique ID, origin, and a payload for topology information. Implement receiveMessage to deduplicate messages using a seen set, update local topology knowledge, and forward messages to neighbors while ensuring idempotency and eventual consistency.

Pro tip: Emphasize that the solution must handle message duplication and reordering gracefully, and that topology inference should be based on accumulating information from multiple messages rather than assuming a single message contains the full picture.

1. Clarify Requirements and Assumptions

Ask about network reliability, message ordering, and whether nodes have persistent storage. Confirm that the goal is eventual consistency of topology knowledge across all nodes.

2. Design Message Format

Define a message structure with a unique message ID, origin node ID, a payload containing topology data (e.g., known nodes, edges, or distances), and a time-to-live or hop count to prevent infinite loops.

3. Implement receiveMessage Logic

On receiving a message, check if it's already been processed (using a seen set of message IDs). If new, update local topology knowledge, then forward the message to all neighbors except the sender (or based on routing logic).

4. Ensure Idempotency and Deduplication

Use a unique message ID and a local set of processed IDs to ignore duplicates. Ensure that processing the same message multiple times does not change the node's state beyond the first time.

5. Accumulate Topology Information

Merge incoming topology data with local knowledge, resolving conflicts (e.g., using timestamps or version numbers). Periodically or upon updates, propagate the merged knowledge to neighbors.

Key Points to Mention

Message deduplication using unique IDs and a seen set to achieve idempotency.
Topology inference through accumulation of partial information from multiple messages.
Handling of message loops and duplicates via TTL or hop count.
Eventual consistency and convergence of topology knowledge across nodes.
Trade-offs between message size, frequency, and convergence speed.
Robustness to node failures and network partitions (if applicable).

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