Katkat
Back

Design favorites and social game recommendations

RobloxSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This question tests the ability to design a scalable, low-latency system for managing user-specific lists (favorites) and integrating real-time social signals into a game recommendation engine.

Problem Statement

Design a backend system for a gaming platform that supports two primary features:

  1. Favorites Management: Allow users to 'favorite' or 'unfavorite' games. Users should be able to view their list of favorites with low latency.
  2. Social Recommendations: Generate a personalized 'Friends Are Playing' feed. A user should see a list of games that their friends have favorited or are currently playing.

Functional Requirements

  • Users can toggle the favorite status of a game.
  • Users can retrieve their personal favorite list.
  • Users can view a list of games currently trending among their friends.

Non-Functional Requirements

  • Scale: Support 50 million DAU and 1 million concurrent users.
  • Performance: Retrieving favorites should be under 50ms (p99).
  • Consistency: The feed doesn't need to be strictly consistent (eventual consistency is acceptable).

Expected Deliverables

  • API definitions for adding favorites and fetching recommendations.
  • High-level system architecture diagram (described in text).
  • Data storage schema, justifying the choice of database (SQL vs NoSQL).
  • Strategy for scaling the recommendation generation as the user base grows.

Example

  • Input (API): POST /v1/favorites {user_id: 123, game_id: 456, action: 'add'}
  • Input (API): GET /v1/recommendations/friends?user_id=123
  • Output: [ {game_id: 789, count: 5}, {game_id: 101, count: 2} ] (Games favorited by friends, sorted by frequency).

Hints

Hint 1

Consider using a combination of a persistent database for source-of-truth storage and an in-memory cache like Redis for fast retrieval of favorite lists.

Hint 2

For the recommendation engine, think about whether to pre-compute friend activity via background workers or perform real-time aggregation at query time.

Hint 3

Use a graph database or a specialized relation store to manage 'friend' edges, as this is a highly read-heavy operation.

Follow-up questions

  • How would you handle the 'fan-out' problem if a high-profile user with 100,000 friends favorites a game?
  • If the database becomes a bottleneck, how would you implement sharding or partitioning for the user-game activity data?
  • How would you modify the recommendation algorithm to account for the recency of the social activity (e.g., weighing a friend's recent favorite more than an older one)?