Identify the K Most Shared Articles in Various Time Windows — System Design Interview Practice

Interview prompt

Design Design a system to track and identify the top K most shared articles in real-time across different time windows. so users can Track article shares in real-time reliably at scale.

• Define the source of truth for Track article shares in real-time; Identify top K articles in different time windows (5 min, 1 hour, 24 hours) and make retries idempotent.
• Use bounded, partitioned state to meet Handle millions of shares per day and Low latency for ranking updates.
• Separate the critical request path from Count-min sketch or approximate counting, Min-heap or priority queue for top K, Stream processing for real-time updates.
• Explain consistency, failure recovery, authorization, observability, and a degraded mode.

Requirements and scale assumptions

• Support the core workflow to Track article shares in real-time.
• Expose status, results, and freshness appropriate to Design a system to track and identify the top K most shared articles in real-time across different time windows..
• Support authorization, validation, updates, deletion, and recovery semantics.
• Meet Low latency for ranking updates under normal load.
• Scale to Handle millions of shares per day without a single hot key or unbounded synchronous work.
• Do not lose committed state; make retries and duplicate events safe.
• Degrade safely when downstream workers, caches, or external dependencies fail.
• Handle millions of shares per day
• Partition by the primary tenant, user, item, or geographic key and isolate hot partitions.
• Keep serving state bounded; retain raw events or durable records for replay and auditing.

• Peak scale: Handle millions of shares per day — Capacity assumption that drives partitioning and backpressure.
• Latency target: Low latency for ranking updates — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — The source of truth is Track article shares in real-time; Identify top K articles in different time windows (5 min, 1 hour, 24 hours).
• Async boundary: At-least-once workers — Keep Count-min sketch or approximate counting, Min-heap or priority queue for top K, Stream processing for real-time updates off the synchronous path.

Key entities

• ScoreEventeventId, itemId, scope, metric, delta, eventTime

  Deduplicated score change for identify the k most shared articles in various time windows.

• WindowStatescope, window, watermark, algorithmVersion, correctionCursor

  Checkpointed event-time state for a ranking window.

• RankSnapshotscope, window, version, items, generatedAt, freshness

  Materialized top-K result with version, ties, and freshness.

• RankingQueryqueryId, scope, window, k, snapshotVersion, nextCursor

  Auditable top-K read contract.

Data flow

1. 1. Accept score evidenceThe identify the k most shared articles in various time windows ingestion boundary validates item scope, event time, source identity, and deduplication before publishing a score event.
2. 2. Aggregate event-time windowsPartitioned workers maintain exact or bounded-approximation identify the k most shared articles in various time windows state with watermarks, late-event policy, and checkpoints.
3. 3. Materialize top-K snapshotsRankers update a sorted candidate structure and publish an atomic snapshot with tie-breaking and error metadata.
4. 4. Serve fresh bounded readsThe query service validates scope and K, reads cache or rank state, and reports stale or approximate results explicitly.
5. 5. Repair and measure churnRebuilds replay retained events while operations tracks lag, error bounds, hot scopes, score corrections, and ranking churn.

Deep dives and trade-offs

• Windowing and late eventsDefine event-time windows, watermark delay, late correction policy, and whether rankings are provisional. Use deterministic tie-breaking so pagination and repeated reads are stable. Checkpoint state and retain events for correction or replay.
• Exact versus approximate top-KUse exact structures for small or low-volume scopes and sketches or candidate heaps when cardinality demands approximation. Expose error bounds and freshness rather than pretending an approximate result is exact. Isolate hot scopes and celebrity items from the main partition budget.
• Freshness and cache correctnessVersion snapshots and cache entries by scope and window so a late update cannot resurrect an older result. Return watermark, generated time, and approximation state to consumers. Measure query tail latency, cache hit rate, update lag, and rank churn together.
• Exact versus approximate rankingChoose based on K, cardinality, update rate, and error tolerance; make approximation visible in the API. Approximation without a measured error bound undermines trust in identify the k most shared articles in various time windows results.
• Push recomputation versus pull queryMaterialize common windows and recompute rare queries on demand with bounded work. Recomputing every query from raw events creates latency spikes and duplicate load.
• Short versus long retentionRetain enough score evidence for late correction and rebuild, then tier older windows. No retained evidence means a ranking bug cannot be repaired reproducibly.