Bird
Raised Fist0

Design Reddit - Voting, Ranking, Community Architecture at Scale

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/5
API Gateway

Receives user vote request

API Gateway accepts HTTP POST /vote with user and post IDs

Protocol:HTTP
BeforeUser vote request is on client device only
AfterVote request forwarded to Vote Service
Vote Service

Processes vote and produces event

Vote Service validates vote and produces event to Kafka topic

Protocol:Kafka Produce
BeforeVote request received but not persisted
AfterVote event durably stored in Kafka
Ranking Service (Apache Flink)

Consumes vote event and updates ranking

Ranking Service processes event stream, recalculates post score

Protocol:Kafka Consume
BeforeRanking data in Cassandra is stale
AfterRanking updated and persisted in Cassandra with new score
Redis Cache

Caches updated ranking and notifies Feed Service

Redis Cache stores updated ranking and triggers feed refresh

Protocol:Redis SET + Pub/Sub
BeforeFeed Service has old ranking data cached
AfterFeed Service notified to refresh feed with new ranking
Feed Service

Fetches community info and generates updated feed

Feed Service queries Community Service for metadata, builds feed

Protocol:gRPC
BeforeFeed Service has outdated feed for user
AfterFeed Service has fresh feed reflecting new vote ranking
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ HTTP POST /vote
        ▼
┌───────────────┐
│  Vote Service │
└───────┬───────┘
        │ Produce Vote Event
        ▼
┌───────────────────────┐
│ Kafka (Vote Events)   │
└───────┬───────────────┘
        │ Stream Vote Events
        ▼
┌───────────────────────────────┐
│ Ranking Service (Apache Flink) │
└───────┬───────────────────────┘
        │ Update Ranking in Cassandra
        ▼
┌───────────────┐
│ Cassandra     │
└───────┬───────┘
        │ Cache Updated Ranking
        ▼
┌───────────────┐
│ Redis Cache   │
└───────┬───────┘
        │ Notify Feed Service
        ▼
┌───────────────┐
│ Feed Service  │
└───────┬───────┘
        │ Query Community Info
        ▼
┌────────────────┐
│ Community Srv  │
└────────────────┘
Design Rationale

This architecture shows a vertical flow of a user vote through the system. The API Gateway receives the vote and forwards it to the Vote Service, which produces a durable event to Kafka. The Ranking Service consumes these events to update post rankings in Cassandra. Redis Cache holds the latest rankings for fast access and notifies the Feed Service to refresh user feeds. The Feed Service queries the Community Service for metadata to personalize feeds. This design decouples vote ingestion from ranking computation and feed generation, enabling scalable, real-time updates with eventual consistency.

Primary Focus

✓

Practice

(1/5)
1. If the Bloom filter component is removed from a Cassandra-like system, what exact failure occurs during a read request for a non-existent key?
medium
A. The system returns stale data from cache without checking disk
B. Every read request for a non-existent key triggers a costly disk lookup, increasing latency and load
C. Writes block until the Bloom filter is rebuilt, causing backpressure
D. The system incorrectly returns key-not-found errors for existing keys due to missing filters

Solution

  1. Step 1: Understand Bloom filter role in reads

    Bloom filters prevent unnecessary disk reads for non-existent keys but do not affect correctness of existing keys.

  2. Step 2: Trace failure without Bloom filters

    Without Bloom filters, reads for non-existent keys cause disk lookups, increasing latency but do not cause incorrect key-not-found errors for existing keys; however, missing Bloom filters can cause stale data to be returned if caching is mismanaged.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Removing Bloom filters risks incorrect key-not-found errors due to stale cache [check]
Hint: No Bloom filter -> stale cache causes wrong misses [check]
Common Mistakes:
2. In a sharded CRDT counter system, what exactly breaks if the shard state replication mechanism fails silently for several minutes?
medium
A. Local shard increments continue, but the global aggregated count lags behind until replication resumes
B. All increments are lost because shards cannot merge without replication
C. The global counter value becomes permanently inconsistent and cannot be recovered
D. The system blocks all increments until replication is restored to maintain consistency

Solution

  1. Step 1: Understand replication role in CRDT counters

    Replication propagates shard states to other replicas for merging. Without it, shards cannot merge and increments are isolated.

  2. Step 2: Trace failure impact

    Without replication, increments on isolated shards are effectively lost from global view until replication resumes; no blocking occurs.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Replication failure isolates shards, causing lost increments globally [check]
Hint: No replication -> isolated shards -> lost global increments [check]
Common Mistakes:
3. If the Signaling Server crashes after forwarding Alice's SDP offer but before receiving Bob's answer, what is the most likely failure observed by Alice?
medium
A. Alice's client receives an immediate error indicating call failure
B. Alice's UI shows ringing indefinitely; the call never connects and no retry occurs
C. The media server starts relaying media streams without session establishment
D. Bob receives the offer twice causing duplicate call setup attempts

Solution

  1. Step 1: Trace failure impact of Signaling Server crash after forwarding offer

    If the server crashes before recording the offer state, it may resend the offer when restarted, causing duplicates.

  2. Step 2: Analyze other options

    No immediate error (A) is unlikely; indefinite ringing (B) happens if answer lost but not duplicated; media server (D) does not start without signaling.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Signaling crash causes duplicate offers, confusing Bob's client [check]
Hint: Signaling crash -> duplicate offers, not silent failure [check]
Common Mistakes:
4. For Pastebin analytics tracking snippet views in real-time, which architecture best balances scalability and data freshness?
medium
A. Use a streaming platform like Kafka to collect events and process them asynchronously in batches
B. Store all view events directly in a relational database with immediate aggregation queries
C. Log view events to flat files and run daily MapReduce jobs for analytics
D. Send view events directly to a NoSQL store with eventual consistency for real-time queries

Solution

  1. Step 1: Analyze real-time analytics requirements

    High throughput and near real-time aggregation require decoupling ingestion and processing.

  2. Step 2: Evaluate architectures

    Kafka streaming (B) supports scalable event ingestion and asynchronous processing; relational DB (A) can't handle high write load; flat files (C) have high latency; NoSQL eventual consistency (D) may cause stale reads.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka decouples ingestion and processing for scalable real-time analytics [check]
Hint: Stream events asynchronously for scalable real-time analytics [check]
Common Mistakes:
5. You must choose between using a HyperLogLog or a Redis Set to count unique users in a high-traffic system with 100 million daily users. Which choice is best and why?
medium
A. Use Redis Set because it provides exact counts and is memory efficient at this scale
B. Use HyperLogLog because it guarantees zero false positives in membership queries
C. Use Redis Set because it supports fast union operations for merging counts
D. Use HyperLogLog because it uses fixed small memory with acceptable error for large cardinalities

Solution

  1. Step 1: Compare memory usage and accuracy

    Redis Sets store all unique IDs exactly, which is memory prohibitive at 100 million users; HyperLogLog uses fixed small memory with ~2% error.

  2. Step 2: Evaluate operational needs

    HyperLogLog supports efficient merges and approximate counts, suitable for large scale; Redis Sets are exact but scale poorly in memory.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    HyperLogLog trades accuracy for fixed small memory at scale [check]
Hint: Fixed small memory + approximate count -> HyperLogLog wins [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