How the interviewer opens it
“Design a service that stores user relationships and answers mutual-connection and neighborhood queries. Support users with many connections and frequent relationship changes.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Relationship meaning
- Query limits
- Graph size
- Traffic and read:write mix
- Latency
- Consistency and availability
- Pages and concurrent changes
- Mutation retries
- Durability and retention
- Scope exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Create, delete, and check a directed follow relationship.
- Return pages of followers and followees.
- Return common followees for two users.
- Return a sample of users reached through two directed edges.
Usually out of scope
- Friend requests and approvals.
- Feed generation and recommendation rank.
- Private accounts and block rules.
- Queries beyond two edges.
What interviewers ask about
- Relationship changes
- Each relationship supports two query directions. Retries and delayed updates can conflict with later changes.
- Users with many connections
- Large lists increase page and query costs. Popular users also concentrate reads and relationship changes.
- Mutual connections
- The service compares lists with very different sizes. Frequent changes make permanent results for every user pair expensive.
- Neighborhood query cost
- A small result can require a huge search. Duplicate paths and large intermediate lists make result limits poor cost limits.
Common mistakes
- The design stores each user's connections in one unlimited record.
- The design treats both edge directions as independent facts without repair.
- The candidate assumes durable writes make every replica read current.
- The design repeats an old mutation after a later opposite change.
- The design limits result size but ignores the number of examined edges.
- The candidate promises complete graph results within fixed latency for every user degree.
The bar by level
- Senior (L5/E5)
- The candidate splits large lists and maintains reverse updates through failures. The design implements edge-scoped retries and linearizable edge checks. The candidate bounds query work and explains page and freshness limits.
- Staff (L6+/E6+)
- The candidate quantifies worst-case query costs and reserves capacity by request class. The design preserves mutation history and cursor progress during partition movement. The candidate defines projection repair and safe delete retention.