How the interviewer opens it
“Design the likes feature for a social network like Facebook. People should be able to like posts and see the counts update live, including on posts by very high-profile users.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- like semantics
- scale and read:write mix
- celebrity bursts
- latency
- consistency
- retries and concurrent devices
- live update behavior
- durability and recovery
- availability and deployment
- existing systems and exclusions
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Like and unlike a post, with at most one active like per user per post
- Read a post's count and the current user's like state
- Push live count updates to viewers
- Handle celebrity-post bursts without losing acknowledged changes
Usually out of scope
- Listing everyone who liked a post
- Other reaction types
- Notifications, feed ranking, and recommendations
- Building authentication or post storage
- Active-active multi-region writes
What interviewers probe
- Correct user state under retries and unlike races
- A counter alone cannot tell whether this user already contributed. Even a desired-state API can misbehave when an old like request is retried after a newer unlike.
- Burst aggregation with exact eventual totals
- The hot post needs both sustained processing capacity and spare capacity after failures. One batched partition may be enough, while striping adds coordination and recovery work. Either approach must avoid permanent drift from retries, replay, and partial recovery.
- Live fanout without per-like delivery
- The viewer multiplier is larger than the write load. Even one update per second to five million viewers is substantial, and reconnects or slow clients can create unbounded work.
Common mistakes
- Treating the count as the source of truth and omitting per-user like state.
- Solving duplicate likes but not delayed retries after an unlike.
- Assuming a hot post either must be striped or fits one partition without checking end-to-end capacity, durability, and recovery headroom.
- Assuming eventual consistency permits permanent overcounting after replay.
- Sizing writes but ignoring the separate cost of millions of live viewers.
- Adding a distributed pipeline without explaining its correctness boundaries, or proposing per-event counter writes without checking the stated burst.
The bar by level
- Senior (L5/E5)
- Gives a coherent state-to-event-to-counter flow, closes the dual-write gap, handles delayed retries, and explains replay and duplicate-publication safety. Justifies a batched single-partition design or a striped design with throughput and recovery calculations. Provides a materialized read path, bounded live delivery, and a practical failure-recovery story.
- Staff (L6+/E6+)
- Makes invariants and failure boundaries explicit across state storage, publication, aggregation, and fanout. Chooses the simplest topology with defensible durability, processing, and catch-up capacity; does not add stripes by reflex. Budgets the two-second freshness target, quantifies fanout, and explains safe rebuilds or repartitioning under live traffic. Distinguishes lag from drift and adapts cold-post cost and degraded operation without weakening acknowledged-write correctness.