PracHub
QuestionsCoachesLearningGuidesInterview Prep
|Home/System Design/Asana

Design a Real-Time Like Counter for Collaborative Tasks

Last updated: Jul 22, 2026

Quick Overview

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.

  • medium
  • Asana
  • System Design
  • Software Engineer

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.

Related Interview Questions

  • Design a Collaborative Todo List - Asana (medium)
  • Design a Twitter-like microblogging service - Asana (medium)
  • Design a Twitter-like service - Asana (medium)
|Home/System Design/Asana

Design a Real-Time Like Counter for Collaborative Tasks

Asana logo
Asana
Jul 16, 2026, 12:00 AM
mediumSoftware EngineerTechnical ScreenSystem Design
4
0

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 Guidance

  • 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 Guidance

  • 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 Guidance

  • 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?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More Asana•More Software Engineer•Asana Software Engineer•Asana System Design•Software Engineer System Design

Your design canvas — auto-saved

PracHub

Master your tech interviews with 8,500+ real questions from top companies.

Product

  • Questions
  • Learning Tracks
  • Interview Guides
  • Resources
  • Premium
  • For Universities

Browse

  • By Company
  • By Role
  • By Category
  • Topic Hubs
  • SQL Questions
  • AI Coding Questions
  • Compare Platforms
  • Discord Community

Support

  • support@prachub.com
  • (916) 541-4762

Legal

  • Privacy Policy
  • Terms of Service
  • About Us

© 2026 PracHub. All rights reserved.