Practice/Oracle/Design a Top-K System

Design a Top-K System

System DesignMust

Problem Statement

Design a system that efficiently retrieves top-k items (songs, videos, hashtags, etc.) based on user activity or engagement metrics within specified time windows. The system should handle real-time data aggregation and support queries like "top 10 songs in the last 7 days" or "trending hashtags in the past 24 hours."

Top-K Ranking is a real-time leaderboard service built into apps like YouTube (trending videos), Spotify (your top songs for the week), Instagram/Twitter (trending hashtags), and Uber Eats (popular restaurants). Users and downstream services request the top K items for a time window and segment (global, region, category, or per user), and expect fast, fresh, and stable results.

Interviewers ask this to test whether you can stream-process high-volume events, maintain time-windowed counts, handle hot keys, precompute results, and serve low-latency reads at scale. Strong answers show a clear separation of write aggregation and read serving, thoughtful handling of late/out-of-order data, and pragmatic tradeoffs between freshness, cost, and correctness.

Key Requirements

Functional

Time-windowed rankings -- retrieve the top K items for fixed windows (last hour, last day, last 7 days, all-time) with a clear freshness target
Segmented results -- scope results by segment such as global, region, category, or per-user rankings
Configurable K -- support different K values (10, 50, 100) with stable, deterministic ordering including tie handling
Paginated responses -- page through results when K is large with consistent, cacheable responses

Non-Functional

Scalability -- handle millions of events per second with heavy skew on popular items during viral periods
Reliability -- tolerate node failures without losing more than a few minutes of ranking data
Latency -- p99 read latency under 100ms for top-K queries; write-to-visibility delay under 10 seconds
Consistency -- eventual consistency is acceptable; rankings should converge within seconds

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Write Path and Event Aggregation

Interviewers want to see how you handle millions of incoming score events without creating database hotspots or losing data. They test whether you understand stream processing, event deduplication, and the difference between raw events and aggregated counts.

Hints to consider:

Use an event streaming platform (Kafka) as a durable buffer between producers and consumers to decouple ingestion from processing
Partition events by item_id to enable parallel processing while maintaining ordering per item
Apply tumbling or sliding windows in a stream processor (Flink) to maintain per-window counts with watermarks handling late arrivals
Batch writes to the storage layer (flush every 5 seconds or 1000 events) to reduce write amplification

2. Handling Hot Keys and Skew

Viral content creates enormous skew where a single item receives 1000x more events than average. Interviewers assess whether you recognize this problem and can propose solutions beyond naive sharding.

Hints to consider:

Implement split counters where hot keys are sharded into N sub-counters and merged periodically
Use probabilistic counting (HyperLogLog for unique counts, Count-Min Sketch for frequency) when exact precision is not required
Apply skew-aware routing where the ingestion layer detects hot items and distributes their events across more partitions
Separate the "top 10" (which changes rarely) from the "long tail" (constantly churning) using tiered storage

3. Maintaining and Serving Top-K Efficiently

Computing top-K by scanning all items on every query is a critical mistake. Interviewers look for pre-computation strategies, appropriate data structures, and cache-friendly designs.

Hints to consider:

Pre-compute top-K lists for each window/segment combination using a stream processor that emits ranked results
Store pre-computed rankings in Redis sorted sets with scores, or a key-value store with TTL matching the window duration
Use min-heaps of size K during aggregation to maintain top candidates efficiently
Implement tiered caching: application cache, CDN, Redis (authoritative), and batch recomputation fallback

4. Time Window Management and Freshness

Different time windows have different update patterns and expiration logic. Interviewers probe whether you understand sliding vs tumbling windows, retention policies, and how to balance freshness with cost.

Hints to consider:

Use tumbling windows for fixed-duration leaderboards (daily resets at midnight) and sliding windows for "last 24 hours" that continuously update
Implement window expiration through TTLs on keys or partition-level deletion in time-series databases
Trade off freshness for cost: update "last hour" every 30 seconds but "last 30 days" only every 5 minutes
Handle late-arriving events with allowed lateness in stream processing (accept events up to 1 hour late)

Practice/Oracle/Design a Top-K System

Design a Top-K System

System DesignMust

Problem Statement

Key Requirements

Functional

Time-windowed rankings -- retrieve the top K items for fixed windows (last hour, last day, last 7 days, all-time) with a clear freshness target
Segmented results -- scope results by segment such as global, region, category, or per-user rankings
Configurable K -- support different K values (10, 50, 100) with stable, deterministic ordering including tie handling
Paginated responses -- page through results when K is large with consistent, cacheable responses

Non-Functional

Scalability -- handle millions of events per second with heavy skew on popular items during viral periods
Reliability -- tolerate node failures without losing more than a few minutes of ranking data
Latency -- p99 read latency under 100ms for top-K queries; write-to-visibility delay under 10 seconds
Consistency -- eventual consistency is acceptable; rankings should converge within seconds

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Write Path and Event Aggregation

Hints to consider:

Use an event streaming platform (Kafka) as a durable buffer between producers and consumers to decouple ingestion from processing
Partition events by item_id to enable parallel processing while maintaining ordering per item
Apply tumbling or sliding windows in a stream processor (Flink) to maintain per-window counts with watermarks handling late arrivals
Batch writes to the storage layer (flush every 5 seconds or 1000 events) to reduce write amplification

2. Handling Hot Keys and Skew

Hints to consider:

Implement split counters where hot keys are sharded into N sub-counters and merged periodically
Use probabilistic counting (HyperLogLog for unique counts, Count-Min Sketch for frequency) when exact precision is not required
Apply skew-aware routing where the ingestion layer detects hot items and distributes their events across more partitions
Separate the "top 10" (which changes rarely) from the "long tail" (constantly churning) using tiered storage

3. Maintaining and Serving Top-K Efficiently

Computing top-K by scanning all items on every query is a critical mistake. Interviewers look for pre-computation strategies, appropriate data structures, and cache-friendly designs.

Hints to consider:

Pre-compute top-K lists for each window/segment combination using a stream processor that emits ranked results
Store pre-computed rankings in Redis sorted sets with scores, or a key-value store with TTL matching the window duration
Use min-heaps of size K during aggregation to maintain top candidates efficiently
Implement tiered caching: application cache, CDN, Redis (authoritative), and batch recomputation fallback

4. Time Window Management and Freshness

Hints to consider:

Use tumbling windows for fixed-duration leaderboards (daily resets at midnight) and sliding windows for "last 24 hours" that continuously update
Implement window expiration through TTLs on keys or partition-level deletion in time-series databases
Trade off freshness for cost: update "last hour" every 30 seconds but "last 30 days" only every 5 minutes
Handle late-arriving events with allowed lateness in stream processing (accept events up to 1 hour late)