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
Design Reddit’s voting, ranking, and community system to handle billions of users and interactions with low latency and high availability.
hardSocial Media and Feed SystemsFreq: high
Prerequisites:System Design FundamentalsCAP TheoremDistributed DatabasesCaching StrategiesEvent-driven Architectures
⚙️
Functional Requirements
  • Users can upvote or downvote posts and comments with real-time feedback.
  • Posts and comments are ranked dynamically based on votes, recency, and community-specific algorithms.
  • Support creation and management of multiple communities (subreddits) with membership and moderation controls.
  • Users can subscribe to communities and receive personalized feeds ranked by relevance and popularity.
  • Moderators can remove posts/comments and manage community rules.
  • Display vote counts and rankings with eventual consistency guarantees.
📊
Non-Functional Requirements
  • Support 2 billion daily active users (DAU).
  • Handle peak write throughput of approximately 1 million vote events per second.
  • Ensure 99.99% availability for voting and ranking APIs.
  • Maintain 100ms P99 latency for vote submission and feed retrieval.
  • Data durability with replication and retention for at least 1 year.
❓
Clarifying Questions to Ask
  • What is the expected ratio of reads to writes for votes and feeds?
  • Are votes allowed to be changed or retracted by users?
  • What is the consistency model required for vote counts (strong vs eventual)?
  • How many communities and posts per community are expected at peak scale?
  • Is real-time ranking required or is eventual consistency acceptable?
  • What are the SLAs for moderator actions like post removals?
Out of Scope
✗ Designing the full Reddit UI/UX or mobile app.
✗ Detailed user authentication and authorization mechanisms.
✗ Content recommendation algorithms beyond ranking signals.
✗ Spam detection and advanced moderation automation.
📌
Assumptions
  • 2 billion DAU with 40 vote actions per user per day on average.
  • Average vote event size is 100 bytes (user_id, post_id, vote_type, timestamp).
  • Peak write QPS is 10x average to handle traffic spikes.
  • Average read QPS is 10x write QPS due to feed retrieval and vote count queries.
⚡
QPS Calculation
write qps2B × 40 / 86400 ≈ 925,926 votes/sec
peak write qps925,926 × 10 = 9,259,260 votes/sec
read qps9,259,260 × 10 = 92,592,600 reads/sec
💾
Storage Estimate
daily storage925,926 votes/sec × 100 bytes × 86400 sec ≈ 8 TB/day
retention days365
total storage8 TB × 365 ≈ 2.9 PB/year
with replication2.9 PB × 3 replicas = 8.7 PB/year
🖥️
Server Estimate
vote ingestionKafka cluster with 100 brokers to handle 9M writes/sec (each broker ~100K writes/sec capacity)
ranking serviceDistributed Flink cluster with 500 nodes for real-time ranking computations at 100M reads/sec
🏗️
Architecture Diagram
Architecture Diagram
          +----------------+
          |  User Clients  |
          +-------+--------+
                  |
                  v
          +-------+--------+
          |  API Gateway   |
          +-------+--------+
                  |
        +---------+----------+
        |                    |
        v                    v
 +------+-----+       +------+-----+
 | Vote Service|       | Feed Service|
 +------+-----+       +------+-----+
        |                    |
        v                    v
 +------+-----+       +------+-----+
 | Kafka (Votes)|       | Cassandra  |
 +------+-----+       +------+-----+
        |                    |
        v                    v
 +------+-----+       +------+-----+
 | Ranking Svc |       | Community  |
 | (Flink)     |       | Service    |
 +------+-----+       +------+-----+
        |                    |
        +---------+----------+
                  |
                  v
          +-------+--------+
          | Redis Cache    |
          +----------------+
🧩
Components
API Gateway
Entry point for all client requests, handles authentication, rate limiting, and routing.
Why thisEnvoy proxy supports high throughput, low latency, and dynamic routing with native gRPC support.
Why notNginx lacks native support for gRPC and dynamic service discovery at this scale.
Vote Service
Handles vote submissions, validates user permissions, and publishes vote events to Kafka.
Why thisStateless microservice allows horizontal scaling to handle 9M writes/sec; decouples ingestion from processing.
Why notMonolithic service would bottleneck and complicate scaling and deployment.
Kafka (Vote Events)
Distributed log for durable, ordered, and scalable ingestion of vote events.
Why thisKafka supports millions of writes/sec with partitioning and replication; enables asynchronous processing.
Why notRabbitMQ cannot handle the required throughput and partitioning at this scale.
Ranking Service (Apache Flink)
Processes vote streams in real-time to compute dynamic rankings per community and post.
Why thisFlink provides low-latency, exactly-once stream processing with stateful operators and windowing.
Why notSpark Streaming has higher latency and weaker exactly-once guarantees.
Cassandra
Stores posts, comments, vote counts, and community metadata with high write throughput and availability.
Why thisCassandra’s wide-column model and tunable consistency fit large-scale time-series vote data with multi-region replication.
Why notPostgreSQL requires complex manual sharding and does not scale linearly at 9M writes/sec.
Community Service
Manages community creation, membership, moderation, and rules enforcement.
Why thisMicroservice with strong consistency requirements uses CockroachDB for distributed SQL with ACID guarantees.
Why notMongoDB’s eventual consistency and lack of strong ACID transactions make it unsuitable for moderation data.
Redis Cache
Caches hot vote counts, rankings, and user subscriptions to reduce read latency.
Why thisRedis TTL natively expires stale data without cron jobs; sub-millisecond lookup supports 100ms P99 latency.
Why notMemcached lacks persistence and advanced data structures needed for ranking caches.
Feed Service
Aggregates ranked posts per user’s subscribed communities and serves personalized feeds.
Why thisStateless service enables horizontal scaling and quick response times for personalized feed retrieval.
Why notStateful monolithic feed servers would limit scalability and increase latency.

Practice

(1/5)
1. In an API gateway request flow, at step 3 the gateway inspects the Accept header to determine API version. What happens if the header is missing or malformed at this step?
easy
A. The gateway rejects the request with a 400 Bad Request error
B. The gateway falls back to a default version configured per service
C. The gateway defaults to the latest API version and forwards the request
D. The gateway forwards the request without versioning information, causing backend ambiguity

Solution

  1. Step 1: Trace gateway header validation at step 3

    The gateway requires a valid Accept header for content negotiation versioning; missing or malformed headers violate protocol.
  2. Step 2: Understand failure handling

    To avoid ambiguous routing or unintended version fallback, the gateway rejects invalid requests with 400 errors rather than guessing versions.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Missing Accept header triggers 400 error at gateway [check]
Hint: Missing Accept header -> gateway rejects request [check]
Common Mistakes:
2. In the web crawler's request flow, at Step 5 the Duplicate Detection component receives a URL. What happens if this URL has been seen before?
easy
A. The URL is discarded and not sent to the Scheduler to avoid redundant crawling
B. The URL is immediately re-queued to the Scheduler for crawling again
C. The URL is marked for delayed re-crawl but still sent to the Scheduler
D. The URL is sent to the Politeness Policy Manager to check domain delays

Solution

  1. Step 1: Understand Duplicate Detection behavior at Step 5

    If the URL has been seen before, it is filtered out to prevent redundant crawling.
  2. Step 2: Eliminate other options

    Re-queuing duplicates wastes resources; marking for delayed re-crawl is a separate process; Politeness Policy Manager handles timing, not duplication.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Duplicate Detection discards seen URLs to avoid redundancy [check]
Hint: Duplicate Detection discards duplicates before scheduling [OK]
Common Mistakes:
3. For a video calling system targeting mobile clients with intermittent connectivity, which architecture best balances latency and reliability for media delivery?
medium
A. Use a multipoint control unit (MCU) media server that mixes all streams into one
B. Use a fully peer-to-peer WebRTC connection with no media server relay
C. Use a selective forwarding unit (SFU) media server to relay streams only when needed
D. Use HTTP Live Streaming (HLS) for media delivery to ensure reliability

Solution

  1. Step 1: Evaluate architectures for mobile intermittent connectivity

    Pure peer-to-peer (A) suffers from connectivity issues; MCU (C) adds latency and CPU overhead; HLS (D) is high latency and not real-time.
  2. Step 2: SFU (B) relays streams selectively, reducing latency and handling network variability well.

  3. Final Answer:

    Option C -> Option C
  4. Quick Check:

    SFU balances latency and reliability for mobile intermittent networks [check]
Hint: SFU relays selectively, best for mobile intermittent connectivity [check]
Common Mistakes:
4. If the trace context extraction component is missing in a downstream service, what is the exact failure observed in the distributed trace?
medium
A. The downstream service starts a new root trace, breaking the parent-child relationship in the trace graph
B. The downstream service's spans are merged incorrectly with upstream spans causing duplication
C. Trace data is lost entirely and no spans are recorded for the downstream service
D. The trace collector rejects spans from the downstream service due to missing context

Solution

  1. Step 1: Understand missing context extraction impact

    Without extracting trace context, the downstream service cannot link its spans to the parent trace, so it starts a new root trace, breaking the trace continuity.
  2. Step 2: Eliminate other failure modes

    Spans are not merged incorrectly; they are disconnected. Spans are still recorded locally, so not lost entirely. Trace collector accepts spans but sees them as separate traces.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Missing extraction causes new root trace, breaking linkage [check]
Hint: No extraction -> new root trace breaks parent-child links [OK]
Common Mistakes:
5. For a faceted search system with frequent filter updates and millions of documents, which architecture better balances update latency and query freshness?
medium
A. Use a near-real-time indexing system that streams document changes to shards asynchronously
B. Use a batch indexing pipeline that rebuilds the entire inverted index every hour
C. Use a write-through cache that updates inverted indexes synchronously on every document change
D. Use a static precomputed index refreshed monthly with manual invalidation

Solution

  1. Step 1: Compare update latency and query freshness trade-offs

    Batch rebuilds have high latency; synchronous writes hurt write throughput; static monthly refresh is too stale.
  2. Step 2: Identify near-real-time indexing benefits

    Streaming updates asynchronously balances freshness and throughput, allowing queries to see recent changes with low delay.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Near-real-time streaming -> balanced freshness and update latency [check]
Hint: Near-real-time streaming balances freshness and throughput [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