Practice/Roblox/Design a Like/Unlike Feature

Design a Like/Unlike Feature

System DesignMust

Problem Statement

Design a system that allows users to favorite and unfavorite items, check whether they have favorited a specific item, view the total favorite count for any item, and browse their personal list of favorited items. This pattern appears everywhere -- liking posts on social media, favoriting products on e-commerce platforms, or bookmarking games on Roblox.

While the user interaction is simple (tap a heart icon), the backend must solve complex distributed systems problems at scale. When a viral item receives millions of favorites in minutes, a single database row tracking the count becomes a write bottleneck. The system must handle concurrent updates without losing data, serve read-heavy traffic (users checking favorite status and counts) with sub-50ms latency, and store billions of user-item relationships efficiently. You also need to prevent a user from favoriting the same item twice, even when retries and network issues cause duplicate requests.

Interviewers use this question to evaluate your understanding of high-throughput data modeling, counter sharding for hot keys, caching strategies with tight consistency requirements, and idempotent write operations.

Key Requirements

Functional

• Favorite and unfavorite -- users can toggle their favorite status on any item, and the system must handle rapid toggling gracefully
• Favorite status check -- given a user and an item, return whether the user has favorited it (must be strongly consistent for the requesting user)
• Favorite count -- display the total number of favorites for any item, tolerating eventual consistency within a few seconds
• Personal favorites list -- users can paginate through all items they have favorited, ordered by recency

Non-Functional

• Scalability -- handle 2 million read queries per second and 150,000 write operations per second across hundreds of millions of users and items
• Latency -- favorite toggle completes within 100ms at p99; count reads return within 50ms at p99; status checks within 30ms at p99
• Reliability -- no favorites are lost; the system degrades gracefully during partial failures with at least 99.95% uptime
• Consistency -- favorite status is strongly consistent per user (read-your-writes); counts are eventually consistent within 5 seconds

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Data Modeling for User-Item Relationships

You need an efficient representation of the many-to-many relationship between users and items that supports fast lookups in both directions: "did user X favorite item Y?" and "what has user X favorited?"

Hints to consider:

• Store user-item favorite records with a composite primary key (userId, itemId) for O(1) status lookups, and maintain separate aggregate count records per item
• Consider wide-column stores like Cassandra that naturally model sparse relationships and support efficient range scans for pagination
• Design the schema to support paginating a user's favorites without full table scans using clustering keys ordered by timestamp
• Think about how to handle favorite toggles (add/remove) atomically without read-modify-write race conditions

2. Counter Sharding for Viral Content

When a popular item receives millions of favorites in minutes, a single counter row becomes a write bottleneck. Naive increment operations will cause lock contention and cascading failures.

Hints to consider:

• Split each item's favorite count across multiple shard rows (e.g., 16 shards); writes go to a random shard, reads aggregate all shards
• Dynamically allocate more shards to trending items detected by monitoring write velocity
• Use write-behind buffering where favorites update an in-memory counter (Redis INCRBY) first, then flush to durable storage in batches
• Consider event streaming architectures that decouple favorite ingestion from count materialization for independent scaling

3. Cache Strategy and Freshness Guarantees

With 2 million read QPS, nearly all traffic must be served from cache, but stale counts frustrate users and stale favorite status causes confusing UI states.

Hints to consider:

• Define explicit staleness budgets: counts can lag by 5 seconds (TTL-based cache), but a user's own favorite status must be immediately consistent
• For favorite status, use read-your-writes consistency by checking the cache first, falling back to the database if the cache entry is missing
• Use Redis INCRBY and DECRBY for real-time count updates in the cache layer to minimize staleness windows
• Run periodic reconciliation jobs that recompute counts from the source of truth to repair any drift from failed cache updates

4. Idempotency and Duplicate Prevention

Network retries, double-taps, and multi-device usage can cause duplicate favorite requests. Your system must handle these without corrupting counts.

Hints to consider:

• Model favorite operations as state transitions (NONE to FAVORITED, FAVORITED to NONE) rather than blind increment/decrement operations
• Use database constraints (unique index on userId, itemId) to prevent duplicate records regardless of retry behavior
• Assign idempotency keys to each request and deduplicate within a time window using a distributed cache
• Ensure count adjustments are derived from actual state changes, not from the number of API calls received

Suggested Approach

Step 1: Clarify Requirements

Confirm the scope and constraints with the interviewer. Ask about the read-to-write ratio and peak traffic profile. Clarify how fresh favorite counts need to be (5-second staleness is typical). Verify that users must see their own favorites reflected immediately (read-your-writes consistency). Estimate the data cardinality: how many users, how many items, and how many total favorites over time. Ask whether the system should support batch favorite checks (e.g., "which of these 20 items has user X favorited?") for rendering feed pages efficiently. Clarify if counts are public and whether there are privacy or rate-limiting concerns.