Design a Real-Time Like Counter for Collaborative Tasks
Company: Asana
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Technical Screen
# Design a Real-Time Like Counter for Collaborative Tasks
Design the backend and client-update flow for a collaborative task product in which signed-in users can like or unlike a task. Everyone currently viewing that task should see the count update promptly. Multiple devices may act concurrently, clients retry requests, and reconnecting viewers must recover the authoritative state.
Focus on the like state, count correctness, subscription lifecycle, and the choice between server-sent events, WebSockets, or another push mechanism. You do not need to design the rest of the task product.
### Constraints & Assumptions
- A user may contribute at most one active like to a task.
- Like and unlike requests can be retried or delivered out of order.
- Exact traffic volume and update-latency goals are not fixed; state reasonable assumptions and explain how the design changes as they grow.
- A brief stale count is acceptable only if the system can converge to the authoritative value.
### Clarifying Questions to Ask
- Must a viewer see its own write immediately, or is eventual confirmation acceptable?
- Are updates only server-to-client, or will the subscription channel also carry client commands?
- Is an exact count required on every read, and what reconnect behavior is expected?
- How many tasks can one client watch at once, and how bursty can a popular task become?
### What a Strong Answer Covers
- A source-of-truth data model that makes duplicate likes impossible
- Idempotent mutation semantics and a clear consistency boundary
- A push path, connection registry, and reconnect or gap-recovery strategy
- Reasoned comparison of SSE and WebSockets based on traffic direction and operations
- Hot-key handling, failure modes, observability, and graceful degradation
### Follow-up Questions
- How would you prevent a delayed unlike from undoing a later like?
- What happens if the database commit succeeds but publication fails?
- How would you support a task that suddenly attracts millions of viewers?
- Can clients safely render optimistic counts, and how should they reconcile?
Quick Answer: Design a real-time like counter for collaborative tasks with one active like per signed-in user. Cover idempotent mutations, authoritative counts, SSE versus WebSockets, reconnect recovery, out-of-order requests, hot keys, and graceful degradation.