This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design user communication functions states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
##### Question
Design a simple in-memory communication manager for users. Implement 2–3 functions to
(
1) connect two users so they can communicate,
(
2) disconnect two previously connected users, and
(
3) clear all existing user communications. Describe your data structures, provide code, and analyze time/space complexity.
Quick Answer: This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design user communication functions states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
Build a simple in-memory component that tracks which users can communicate with each other. Treat a communication link between two users as an undirected connection (if A can talk to B, then B can talk to A). Assume user IDs are hashable (e.g., strings or integers) and that the system runs in a single process.
Requirements
Implement the following functions:
connect(user_a, user_b): Create a bidirectional connection so the two users can communicate.
disconnect(user_a, user_b): Remove an existing bidirectional connection, if present.
clear(): Remove all existing user communications.
Also:
Describe the data structures you use.
Provide code for the above API.
Analyze the time and space complexity.
Assumptions
Connections are undirected and idempotent (calling connect twice for the same pair should not create duplicates or errors).
Self-connections (a user connected to itself) should be rejected or ignored.
Disconnecting a non-existent connection should be a no-op.
Creating a connection for users not yet seen should implicitly add them to the system.
Clarifying Questions to Ask Guidance
Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.
What a Strong Answer Covers Guidance
A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.
Follow-up Questions Guidance
What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?