How the interviewer opens it
“Design a service that returns the most shared articles over the last 5 minutes, 1 hour, and 24 hours. Clients should be able to request the top K articles for any of those windows.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- ranking and query shape
- share identity and duplicates
- event scale
- reads and read:write mix
- latency and freshness
- time boundaries and late events
- accuracy and availability
- durability and recovery
- traffic skew
- scope exclusions
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Consume article-share events and count each canonical share once
- Maintain global rankings for the last 5 minutes, 1 hour, and 24 hours
- Return the top K article IDs and share counts
- Expire old contributions even when an article receives no new shares
Usually out of scope
- Personalized recommendations or growth-rate scoring
- Distinct-user counting and bot detection
- Arbitrary time-range queries
- Article search, content storage, and metadata hydration
What interviewers probe
- Sliding-window expiration and event time
- An article can leave the leaderboard without receiving another event. Three overlapping windows need different expiration times, and late events must update the right buckets without delaying every result by two minutes.
- Correct distributed top K as scores decrease
- Local top-K lists are sufficient only under the right partitioning. Expiration also means previous losers can become winners, so retaining only current winners loses information.
- A viral article that overloads one key
- Hash partitioning balances many articles but cannot split one article's raw event rate. Any split must still produce one complete article score before global ranking, without losing deduplication or bucket identity.
- Share-ID deduplication and recovery without count corruption
- Exactly-once processing of log offsets does not deduplicate the same share appended twice. Deduplication markers, their expiry, downstream contributions, and replay positions must agree, including after a long outage.
Common mistakes
- Maintaining lifetime counts or relying on cache TTL instead of expiring bucket contributions.
- Merging local top-K candidates from event-sharded partial counts without proving candidate completeness.
- Keeping only the current K winners, leaving no way to promote replacements when scores decrease.
- Scanning the full event history per query or allocating a dense 24-hour bucket array for every article.
- Assuming more article hash partitions solve one viral article's raw-event load.
- Treating checkpoint-based exactly-once processing as share-ID deduplication, or giving deduplication state a wall-clock TTL that is unsafe during recovery.
The bar by level
- Senior (L5/E5)
- Separates share-ID partitioning from article ownership, deduplicates before aggregation, proves the local-top-K merge is correct, and handles late events and idle expiration. Gives a concrete hot-key strategy and explains how deduplication markers, source offsets, count state, and downstream effects recover together. Estimates both bucket history and deduplication state.
- Staff (L6+/E6+)
- Defines precise admission, snapshot, and replay contracts; proves a safe deduplication retention policy rather than equating exactly-once offsets with unique shares. Follows guarantees through partial aggregation, publication barriers, ownership changes, and full rebuilds. Quantifies persistent-state overhead, replay capacity, and recovery time, and identifies which accuracy or freshness guarantees would need to change if those costs become unacceptable.