Bird
Raised Fist0

Design Reddit - Voting, Ranking, Community Architecture at Scale

HLDhardInterview freq: high
Choose your preparation mode4 modes available
🎯
Design Reddit - Voting, Ranking, Community Architecture at Scale
45 min · senior
senior

You are tasked with designing the backend architecture for a Reddit-like platform serving 50 million daily active users (DAU). The system must support voting on posts and comments, ranking content dynamically, and managing communities (subreddits) with membership and moderation features. The platform must handle high write and read throughput with P99 latency under 200ms, ensure vote integrity and consistency, and encrypt sensitive user data at rest and in transit.

  • P99 read and write latency must be under 200ms at 50M DAU scale
  • All votes must be strongly consistent to prevent vote manipulation
  • Content ranking must update in near real-time (within seconds) to reflect votes and new posts
  • User data and votes must be encrypted at rest and in transit to comply with privacy regulations
  • Community membership and moderation actions must be auditable and consistent
  • System must support eventual offline delivery of notifications without impacting core voting and ranking latency
📋
Guided Steps
1/5
Step 1
Designing the Voting System
How would you design the voting mechanism to handle 50M DAU with strong consistency and low latency?
💡 Hint
Consider a write-optimized, distributed store with atomic counters and idempotent writes.
Use Apache Cassandra with a partition key on (post_id, user_id) for vote records to ensure idempotent writes and strong consistency via lightweight transactions (LWT) for vote updates.
Mid-level: Names Cassandra for scalability. Senior: Explains why LWT is needed for vote integrity and why relational DBs like MySQL would bottleneck at 50M DAU.
⚠️Common Wrong Answer
Using a relational database with row-level locks for votes - leads to write contention and high latency at scale.
Step 2
Ranking Algorithm and Real-Time Updates
How would you design the ranking system to update scores in near real-time and serve ranked content with P99 < 200ms?
💡 Hint
Think about streaming vote events and incremental score computation with fast read caches.
Use Apache Kafka to stream vote events to a Flink cluster that computes ranking scores in real-time, storing results in Redis sorted sets for sub-200ms ranked retrieval.
Mid-level: Mentions Kafka for event streaming. Senior: Details Flink for stateful stream processing and Redis sorted sets for O(log N) ranked queries with TTL eviction.
⚠️Common Wrong Answer
Batch recomputing rankings every few minutes - causes stale rankings and poor user experience.
Step 3
Community Membership and Moderation
How would you design community membership and moderation features ensuring consistency and auditability?
💡 Hint
Consider a strongly consistent store with immutable audit logs and role-based access control.
Use Google Cloud Spanner for community membership with strong consistency and global distribution, combined with Apache Kafka for immutable audit logs of moderation actions.
Mid-level: Suggests a database for membership. Senior: Explains why Spanner’s global consistency is critical and Kafka audit logs enable tamper-proof moderation history.
⚠️Common Wrong Answer
Using eventual consistent NoSQL stores for membership - leads to stale membership views and inconsistent moderation enforcement.
Step 4
Ensuring Data Encryption and Security
How would you ensure encryption of user data and votes both at rest and in transit without impacting latency?
💡 Hint
Look for native encryption features and TLS termination close to clients.
Enable TLS 1.3 for all client-server and inter-service communication, and use Cassandra’s Transparent Data Encryption (TDE) for at-rest encryption with hardware security modules (HSM) for key management.
Mid-level: Mentions TLS and encryption. Senior: Details TLS 1.3 benefits for low latency and Cassandra TDE integration with HSM for compliance and minimal performance impact.
⚠️Common Wrong Answer
Encrypting data at application layer only - adds latency and complexity, risking inconsistent encryption coverage.
Step 5
API Design for Voting, Ranking, and Community
Sketch 3 core API endpoints for voting, fetching ranked posts, and managing community membership. What are the key request and response fields?
💡 Hint
Consider idempotency, pagination, and authorization tokens.
POST /vote with (user_id, post_id, vote_value, idempotency_key); GET /posts/ranked with (community_id, cursor, limit); POST /community/join with (user_id, community_id, auth_token).
Mid-level: Lists endpoints and basic fields. Senior: Explains idempotency_key for exactly-once vote processing, cursor-based pagination for ranked posts, and JWT tokens for membership auth.
⚠️Common Wrong Answer
Using simple POST /vote without idempotency - causes duplicate votes under retries.
🔌
API Design Challenge
Sketch 3 core API endpoints for the Reddit-like system focusing on voting, ranking retrieval, and community membership management.
  • How does the client submit a vote and ensure it is counted exactly once?
  • How does the client fetch ranked posts efficiently with pagination?
  • How does the client join or leave a community and how is membership verified?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Strongly consistent vote storage with Cassandra LWT to prevent vote manipulation
  • Real-time ranking updates using Kafka and Flink streaming with Redis for fast reads
  • Strongly consistent community membership with audit logs for moderation
  • Encryption at rest and in transit with minimal latency impact
Good to Have - 30%
  • Idempotent API design with idempotency keys and cursor-based pagination
  • Use of hardware security modules (HSM) for encryption key management
  • Immutable Kafka audit logs for compliance and traceability
Bonus - 10%
  • Design considerations for offline notification delivery without impacting core latency
  • Discussion of multi-region deployment for global user base
Using relational databases with row-level locking for votes - causes write contention and high latency at 50M DAU, leading to system bottlenecks and poor user experience.
Batch recomputation of rankings - leads to stale content and poor user experience due to delayed updates and outdated rankings.
Eventual consistency for community membership - causes inconsistent moderation and stale views, risking incorrect access control and user confusion.
Application-layer encryption only - increases latency and risks inconsistent coverage, potentially exposing sensitive data during transmission or storage.
HTTP polling at 50M DAU: 50 million reconnects per minute just to check for messages - collapses under load and wastes resources, degrading system performance.
✅
Model Answer
▼ Reveal

This design addresses the challenges of building a Reddit-like platform at 50M DAU scale with strict latency and consistency requirements. It uses scalable, strongly consistent databases and streaming technologies to ensure vote integrity, real-time ranking, and consistent community management. Security is enforced via TLS 1.3 and hardware-backed encryption. The API design supports idempotency and efficient pagination.

  • Use Cassandra with partition key (post_id, user_id) and lightweight transactions to ensure vote updates are atomic and idempotent.
  • Stream vote events via Kafka to Flink for incremental ranking score computation, storing results in Redis sorted sets for low-latency retrieval.
  • Employ Google Cloud Spanner for globally consistent community membership data and use Kafka to maintain immutable audit logs for moderation.
  • Enable TLS 1.3 for all client and inter-service communication to minimize encryption overhead and use Cassandra TDE with HSM for secure key management.
  • Design APIs with idempotency keys for vote submissions to prevent duplicates, cursor-based pagination for ranked posts, and JWT tokens for secure community membership management.
  • Apache Cassandra with partition key (post_id, user_id) and LWT for vote consistency
  • Apache Kafka for streaming vote events to ranking processors
  • Apache Flink for real-time ranking score computation with stateful stream processing
  • Redis sorted sets for low-latency ranked content retrieval with TTL eviction
  • Google Cloud Spanner for strongly consistent community membership and moderation data
  • Kafka immutable audit logs for tamper-proof moderation history
  • TLS 1.3 for all network communication to minimize latency overhead
  • Cassandra Transparent Data Encryption (TDE) with HSM for secure key management
  • API design with idempotency keys for vote submissions and cursor-based pagination for ranked posts
  • JWT-based authorization tokens for community membership and moderation actions

Practice

(1/5)
1. In a Count-Min Sketch system, at step 3 the Update Worker hashes an incoming event key with the second hash function. What happens to the corresponding counter in the sketch at this step?
easy
A. The counter is reset to zero before incrementing
B. The counter at the hashed index is incremented by one
C. The counter is decremented to avoid overcounting
D. The counter is replaced with the maximum of current and new value

Solution

  1. Step 1: Understand Update Worker hashing

    Each hash function maps the event key to an index in the sketch array.
  2. Step 2: Increment counter at hashed index

    The Count-Min Sketch increments the counter at that index to record the event occurrence.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Update increments counters at hash indices to track frequencies [check]
Hint: Update increments counters at hash indices, never resets or decrements [check]
Common Mistakes:
2. In the order processing pipeline, at step 5 the Inventory Service checks stock availability. What is the state of the order if the Inventory Service finds insufficient stock at this step?
easy
A. Order is immediately cancelled and removed from the system
B. Order is marked as 'Confirmed' but flagged for manual review
C. Order status is updated to 'Pending Stock' and placed in a retry queue
D. Order processing continues but with a backorder flag set

Solution

  1. Step 1: Trace Inventory Service check at Step 5

    Inventory Service detects insufficient stock and cannot confirm order immediately.
  2. Step 2: Understand retry mechanism

    System updates order to 'Pending Stock' and enqueues it for retry once stock replenishes, avoiding immediate cancellation or false confirmation.
  3. Final Answer:

    Option C -> Option C
  4. Quick Check:

    Insufficient stock -> 'Pending Stock' + retry queue [check]
Hint: Insufficient stock triggers retry queue, not immediate cancel [check]
Common Mistakes:
3. A social media platform must handle 1 million tweet writes per second and fan-out to millions of followers asynchronously. Which component best decouples tweet ingestion from timeline delivery to ensure durability and scalability?
easy
A. Use a relational database with immediate fan-out triggers on write
B. Use a distributed log system like Kafka partitioned by user ID
C. Use an in-memory cache like Redis for immediate fan-out
D. Use a direct synchronous RPC call to each follower's timeline service

Solution

  1. Step 1: Identify the role of the distributed log

    Kafka partitions by user ID to preserve ordering and durability, decoupling ingestion from delivery.
  2. Step 2: Eliminate other options

    Relational DB triggers (A) cause synchronous blocking and don't scale; Redis (C) lacks durability and persistence; synchronous RPC (D) blocks on follower availability.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Kafka partitions ensure durable, ordered, asynchronous fan-out [check]
Hint: Distributed log decouples ingestion and delivery [check]
Common Mistakes:
4. For a globally distributed key-value store requiring low write latency and strong consistency, which replication approach is best and why?
medium
A. Single-leader replication with leader in primary region only
B. Asynchronous replication with conflict resolution on reads
C. Synchronous replication with majority quorum writes to all regions
D. Synchronous replication with local quorum writes per region and global reconciliation

Solution

  1. Step 1: Evaluate latency and consistency trade-offs

    Global synchronous quorum to all regions (A) causes high latency; asynchronous (B) sacrifices strong consistency.
  2. Step 2: Consider local quorum with global reconciliation

    Local quorum writes reduce latency while global reconciliation maintains strong consistency.
  3. Final Answer:

    Option D -> Option D
  4. Quick Check:

    Local quorum + global reconciliation balances latency and consistency [check]
Hint: Local quorum writes reduce latency, global reconciliation ensures consistency [check]
Common Mistakes:
5. At 10x scale, which component in Spotify's streaming architecture is most likely to fail first and why?
hard
A. The metadata database due to increased write contention on user playlists
B. The streaming servers because maintaining millions of concurrent WebSocket connections is stateful and hard to shard
C. The CDN edge caches due to limited storage capacity per region
D. The offline download manager due to device storage limits

Solution

  1. Step 1: Identify stateful bottlenecks at scale

    Streaming servers maintain WebSocket connections which are stateful and tied to server memory.
  2. Step 2: Evaluate scaling challenges

    Metadata DB (A) can be sharded; CDN caches (B) scale by adding regions; offline manager (D) limited by device, not server scale. Streaming servers (C) face connection limits and resharding complexity.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Stateful WebSocket servers fail first at 10x scale [check]
Hint: Stateful WebSocket servers bottleneck at scale [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard