Roblox·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

May 2026

Summary

System design round at Roblox for a software engineer role, focused entirely on building a like/unlike feature at massive scale. The question had a lot of moving parts and pushed into some areas I hadn't fully thought through before.

Questions Asked (1)

Design a Like/Unlike feature for a social platform that handles millions of read requests per second, shows total like counts, shows whether the current user has liked an item, and optionally lists users who liked an item with pagination.

System DesignData ModelingTechnical Trade-offs

Author's notes

I started with the data model, a user_likes table with a composite key, and that part went fine.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then design a read-optimized architecture that separates the hot path (like counts and user like status) from the cold path (listing likers). Propose a denormalized counter store with caching for counts, a fast membership store for user-like status, and a separate storage for the liker list with pagination. Discuss trade-offs between consistency, latency, and cost, and how to handle write spikes and cache invalidation.

Pro tip: Emphasize that the read path must be served from memory (e.g., Redis or a custom in-memory store) with asynchronous writes to durable storage, and that eventual consistency is acceptable for like counts as long as the user's own like status is immediately consistent.

1. Clarify requirements and scale

Ask about read/write ratio, latency targets, consistency needs, and whether the liker list is a core feature. Confirm that reads dominate (millions per second) and that counts can be eventually consistent.

2. Design the data model

Propose separate stores: a counter store (e.g., Redis or a distributed counter service) for total likes, a membership store (e.g., a set or bitmap per item) for user-like status, and a durable log or table for the liker list. Consider using a unique like ID to deduplicate.

3. Architect the read path

Serve like counts and user-like status from an in-memory cache or a read-optimized store with replication. Use local caching or a CDN for counts if possible. Ensure the user-like status check is O(1) and low-latency.

4. Architect the write path

Handle likes/unlikes by writing to a durable queue (e.g., Kafka) and asynchronously updating the counter and membership stores. Use idempotent operations and consider batching to handle spikes.

5. Address pagination and trade-offs

For listing likers, use a separate service with a sorted set or time-series database, paginate by cursor (e.g., timestamp or like ID). Discuss trade-offs: eventual consistency vs. strong consistency, memory cost vs. latency, and how to handle hot items.

Key Points to Mention

Use of in-memory data stores (Redis, Memcached) for low-latency reads of counts and user-like status.
Denormalization and materialized views to avoid expensive joins on the read path.
Eventual consistency for like counts, with immediate consistency for the user's own like status.
Asynchronous write processing via message queues to absorb spikes and ensure durability.
Sharding and replication strategies to scale reads horizontally.
Pagination techniques (cursor-based) and separate storage for the liker list to avoid impacting the hot path.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.