Design a service that ranks drivers from customer reviews and serves a top-driver leaderboard. The system must accept immutable review events containing a driver identifier, a numeric rating, and an event time. It must expose a driver's current aggregate rating and return the top `k` drivers. Discuss how a new or corrected review changes the ranking without rebuilding all historical data. ### Constraints & Assumptions - Clarify the rating scale, whether a reviewer may submit more than one active review for a driver, and how ties are broken. - Rankings should be deterministic and should not double-count retried review submissions. - Reads may be slightly stale if you define and justify a freshness target. ### Clarifying Questions to Ask - Is the leaderboard global, regional, or filtered by a time window? - Do edits replace a prior review or create a new version? - Is the score a simple average, a weighted score, or a separately owned policy? ```hint Separate facts from projections Keep the review event as the durable fact and treat the aggregate score and top-k ordering as rebuildable views. ``` ### What a Strong Answer Covers - Review ingestion, idempotency, validation, and an immutable audit trail. - Incremental aggregates that retain both a rating sum and count rather than averaging averages. - A deterministic ranking key, scalable top-k reads, and a plan for review edits or retractions. - Reconciliation between the source of truth and derived leaderboard state. ### Follow-up Questions - How would you add a seven-day regional leaderboard without corrupting the all-time ranking? - How would you detect and repair a missed aggregate update? - What changes if the scoring policy is versioned?