Katkat
Back

Design a Scalable Likes System

RobloxSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This question tests your ability to design a high-throughput, distributed service for tracking user engagement, focusing on write-heavy loads and read-consistency trade-offs.

Design a Scalable Likes System

Design a global 'Likes' service for a platform like Roblox, where millions of users can like items (games, assets, or comments) simultaneously. The system must support high-frequency updates and provide responsive reads for UI components.

Requirements

  1. Functional Requirements

    • A user can 'like' or 'unlike' an item.
    • Retrieve the current like count for a specific item.
    • Check if the current user has already liked a specific item.

  2. Non-Functional Requirements

    • Handle millions of active users and high write throughput (e.g., 50k likes/second).
    • Provide low-latency read access to like counts.
    • Ensure high availability for the service.

  3. Scale Assumptions

    • Total items: 100 million.
    • Total active daily users: 50 million.
    • Read/write ratio: 10:1.

Expectations

Provide a high-level architecture diagram or description covering:

  • API Design: Define the endpoints for interacting with the service.
  • Data Model: Choose appropriate storage solutions (e.g., Relational vs. NoSQL) and explain your schema.
  • Scalability Strategy: How do you handle extreme spikes in likes for trending items? How do you prevent database hotspots?
  • Consistency: Explain the trade-offs between strong consistency (real-time counts) and eventual consistency (buffered counts).

Hints

Hint 1

Consider using a distributed caching layer like Redis to handle hot keys and buffer incoming writes before flushing them to permanent storage.

Hint 2

Decide whether to store the raw 'like' events (every user action) or maintain a running aggregate count, and weigh the trade-offs regarding storage cost and auditability.

Hint 3

Think about sharding the database or cache based on item_id to distribute the write load evenly across multiple nodes.

Follow-up questions

  • How would you modify your design if you needed to display a list of the last 50 users who liked a specific item?
  • If the service experiences a massive spike due to a viral item, how can you prevent the backend database from crashing?
  • How would you ensure that a user cannot 'like' the same item multiple times via race conditions in your distributed environment?