How the interviewer opens it
“Design a social network whose independently operated servers exchange posts and follow events. Users can follow users on other servers and delete their own posts.”
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
- Network and server scale
- Traffic and read:write mix
- Feed size and follow distribution
- Payload, destinations, and retention
- Product behavior
- Latency and consistency
- Durability
- Peer outages
- Deletion guarantees and operating limits
- Trust, protocol, and 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
- Publish public text posts and show a local feed
- Follow and unfollow users on other servers
- Exchange events despite peer failures
- Apply post deletions on servers that follow the protocol
Usually out of scope
- Private posts and direct messages
- Media storage
- Post edits
- Search and account moves
What interviewers ask about
- Delivery to remote servers
- One post can reach thousands of independent servers. Uncertain acknowledgments and long outages must not stop local actions or healthy traffic.
- Follow state across servers
- Follow, acceptance, and cancellation can arrive in different orders. An old event must not change a newer relationship.
- Post deletion
- Deletion can precede creation or follow a long outage. Remote deadlines need clear operating limits, and independent operators control their own copies.
- Local feeds
- Follow counts vary widely. A cheap post write can create expensive feed reads or a large burst of local updates.
Common mistakes
- Assumes a central server can order events or enforce rules across all operators.
- Makes local requests wait for remote peers.
- Treats event arrival order as the correct order for follows and deletions.
- Confuses asynchronous database replication with durable acknowledgment across independent machines.
- Promises deletion deadlines without bounds on traffic, peer latency, or queue delay.
- Claims that a feed query meets its latency target without follow counts, page size, or peak load.
The bar by level
- Senior (L5/E5)
- Resolves follow races and deletion before creation. Preserves acknowledged work across one machine failure. Sizes peer backlogs correctly and selects a feed path from the workload.
- Staff (L6+/E6+)
- Defines authority, repair, and retention rules across operators. Derives deletion deadlines from traffic limits, peer latency, and reserved capacity. Separates live deadlines from repair. Addresses safe failover, peer abuse, and limits on remote erasure.