Katkat
Back

Design a Real-Time Like Counter for Collaborative Tasks

AsanaSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This problem tests the ability to design a distributed, high-concurrency counter system that maintains strict consistency while ensuring low-latency updates for collaborative task management.

Problem Statement

Design a scalable real-time "Like" counter system for a collaborative task management application (like Asana). Users can "like" or "unlike" a task, and the total count must be updated and broadcast to all users viewing the task in real-time.

Functional Requirements

  • Users can toggle a "Like" status on a task.
  • A user can only have one active "Like" per task.
  • The total like count must be visible to all users currently viewing the task.

Non-Functional Requirements

  • Real-time updates: Latency should be under 500ms for clients.
  • High Availability: The system should remain responsive even if one database instance fails.
  • Consistency: The count must eventually be accurate, and ideally consistent for individual users (e.g., if I like a task, I should immediately see the count increment).
  • Scale: Support up to 10,000 concurrent viewers per task and thousands of tasks across the platform.

Deliverables

  1. API design (REST or GraphQL) for toggling likes and fetching current counts.
  2. High-level architecture diagram describing the interaction between clients, load balancers, application servers, and persistence layers.
  3. Mechanism for handling "hot keys" (popular tasks getting thousands of likes per second).
  4. A description of how to handle connection drops and state reconciliation for real-time clients.

Constraints

  • Assume 100,000 DAU with fluctuating traffic.
  • Must ensure idempotency for duplicate like requests.

Hints

Hint 1

Consider using an in-memory data store like Redis with atomic increment/decrement operations for the hot path.

Hint 2

Evaluate the trade-offs between WebSockets for bi-directional streaming and Server-Sent Events (SSE) for server-to-client updates.

Hint 3

Implement a write-behind strategy or asynchronous queue to batch database updates to the persistent storage to reduce write pressure.

Follow-up questions

  • How would you handle a scenario where the Redis counter becomes desynchronized from the source-of-truth SQL database?
  • If a task goes viral, how would you prevent the WebSocket server from becoming a bottleneck during the 'thundering herd' of status updates?
  • How does your system handle out-of-order events if the user clicks like and unlike in rapid succession?