sesame·Software Engineer·Onsite - System Design / Architecture·Intermediate

Intermediate

Jul 2026

Summary

System design round at Sesame for a software engineer role. The whole session was basically one big networking question dressed up as a product feature, which I wasn't fully expecting.

Questions Asked (1)

Design a TCP-based chat server where multiple clients can connect, messages get broadcast to all other clients, and the server handles clients joining and leaving without crashing. Walk through your concurrency model, how you'd frame messages on the byte stream, and how you'd do a clean shutdown.

System DesignTechnical Trade-offs

Author's notes

I started with thread-per-connection because it's the obvious answer, but they pushed back pretty fast on what happens at 10k clients.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then propose a thread-per-connection model with a shared client registry and broadcast queue, explaining how it handles joins/leaves. Detail message framing with length-prefixed messages and a clean shutdown sequence using a shutdown flag and socket closure.

Pro tip: Mention that you'd use a write queue per client to avoid blocking the broadcast loop on slow consumers, and that you'd test with abrupt disconnects to ensure the server doesn't crash.

1. Clarify Requirements and Scale

Ask about expected number of concurrent clients, message size, and whether ordering or delivery guarantees are needed. This informs the concurrency model and framing choices.

2. Choose Concurrency Model

Propose a thread-per-connection model for simplicity, or an event-driven model (e.g., epoll) for high scalability. Explain how a shared data structure (e.g., concurrent set) tracks active clients and synchronizes broadcasts.

3. Design Message Framing

Use length-prefixed framing: a fixed-size header (e.g., 4-byte big-endian length) followed by the payload. This handles TCP stream boundaries and allows the server to read complete messages.

4. Handle Joins, Leaves, and Broadcast

On join, add the client to the registry; on leave (detected by read returning 0 or an error), remove it and close the socket. Broadcast by iterating over a snapshot of the registry and enqueuing messages to each client's write queue.

5. Implement Clean Shutdown

Use a shutdown flag and close the listening socket to stop accepting new connections. Signal all client threads to exit, drain write queues, and join threads before exiting the process.

Key Points to Mention

Thread-per-connection vs. event-driven (e.g., epoll) trade-offs for scalability and complexity.
Length-prefixed framing to handle TCP stream boundaries and partial reads.
Concurrent client registry (e.g., concurrent hash map or mutex-protected set) for thread-safe joins/leaves.
Per-client write queue to prevent slow clients from blocking broadcasts.
Graceful shutdown: stop accepting, signal threads, drain queues, join threads.
Error handling: catch exceptions on read/write, remove dead clients, and avoid crashing.

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