Katkat
Back

Design a Played-By Summary System

RobloxSoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

Design a scalable social-proof service that tracks unique player counts per experience and computes real-time friend-intersection summaries under high write throughput and low read latency.

Scenario

On a global gaming platform, every experience (game) detail page displays a social-proof summary: "Played by 12.4M players, including your friends Alice, Bob, and 3 others."

Design the end-to-end backend service that powers this "Played-By" summary feature. The system must ingest high-volume gameplay session events, maintain accurate unique-player counts, and rapidly compute the set of friends who have played a specific experience when a user views its landing page.

Requirements

Functional Requirements

  1. Record Plays: Ingest session events when players join or complete an experience, recording that user U has played experience E.
  2. Total Unique Count: Return the total count of distinct players who have played experience E (all-time or within a rolling 30-day window).
  3. Friend Attribution: When user V (viewer) requests the summary for experience E, return the count and profiles of up to K friends (e.g., K = 5) who have played E.

Non-Functional Requirements

  • Scale: 80M daily active users (DAU), 350M monthly active users (MAU), and over 10M peak concurrent users. Average user has 50 friends; some power users have up to 1,000 friends.
  • Write Throughput: 50,000 session start events/sec average, peaking at 150,000 events/sec. Viral experiences may receive 20,000+ session starts/sec alone.
  • Read Latency: p99 < 50ms for the experience detail page read API.
  • Freshness & Consistency: Eventual consistency is acceptable (e.g., updates reflected within 1–2 minutes). Overcounting or duplicate counting from retried events must be prevented.

Key Areas to Cover

  1. API & Data Ingestion: Define the write and read contracts. Detail the event ingestion pipeline and deduplication mechanism to handle duplicate play events.
  2. Unique Player Counting: Propose a storage and computation strategy for tracking distinct players per experience at scale (e.g., exact vs. approximate counts like HyperLogLog, persistent unique sets).
  3. Friend Intersection Engine: Explain how the system determines which of the viewer's friends have played experience E without performing expensive fan-out joins on every page load.
  4. Hotspots & Caching: Mitigate read and write bottlenecks caused by top-tier viral games with millions of concurrent players.

Hints

Hint 1

Decouple the global unique counter from the per-user social graph intersection; they have fundamentally different read/write patterns and consistency tolerances.

Hint 2

For the friend intersection, consider whether you should query 'friends of user V who played experience E' or fetch 'user V's friend IDs' and check their membership in experience E's player set (or vice versa).

Hint 3

To handle write hotspots on viral games, buffer play events via distributed queues and use bloom filters or distributed caches to discard repeated plays by the same user within short intervals before touching persistent storage.

Follow-up questions

  • How would you modify your design if the requirement changed from all-time played history to a rolling 'played in the last 7 days' window?
  • If a user has 5,000 friends and the experience has 20 million players, how do you decide whether to test friend IDs against the game's player base or game IDs against the friends' played lists?
  • How does your architecture handle user privacy controls (e.g., a friend chooses to hide their gameplay activity) without severely degrading read cache hit rates?