Strengths

• Coverage of Functional and Non-Functional Requirements: You proactively listed most functional requirements (e.g., score updates, global ranking, time-bounded boards) and included numeric metrics for NFRs like latency and scale, showing awareness of production constraints.
• Multi-Dimensional Thinking: You considered various leaderboard dimensions — region, seasonality, game mode — which reflects real-world complexity and scope planning.
• Architecture Tradeoffs: You discussed offline vs online ranking strategies (e.g., Spark + scheduler vs. Redis ZSETs) and could articulate pros/cons clearly.
• Core Components and Data Flow:
  • Used Redis ZSET and explained operations like ZADD effectively.
  • Brought up Kafka queues and DB sharding by game_id for decoupling and scale.
  • Thought through tiered storage for heavy write loads and Redis partitioning via leaderboard_id.
• API and Idempotency:
  • Attempted to drive API signatures with structure.
  • Noted idempotency via event_id, which is a solid signal of reliability engineering awareness.
• Resilience & Scaling: Discussed Redis cluster fallback from offline jobs, and partitioning/caching strategies to mitigate potential bottlenecks.

Improvement Areas

• Missing Assumption Alignment: You skipped early alignment on key problem axes like game modes, regional split, or time windows — this could lead to mis-scoping. Always pause in the first 3–5 mins to confirm scope and constraints with the interviewer.
• Incorrect API Signature: Your POST API for score updates was missing critical fields — it lacked both player_id and the actual score in the request body. That’s a red flag in a real interview. Nail down the contract early.
• Leaderboard Size Misalignment: You assumed very large leaderboard sizes without asking about expected cardinality (e.g., 100M players vs. 1M). This impacted your component and Redis design. Always ask about data size and access patterns.
• Redis Hotspot Issue: You didn’t fully address hot shards — e.g., repeated top-10 reads on global leaderboards. Interviewers want to hear about celebrity cache, top-N materialization, or sharded read replicas.
• Kafka → Redis Data Flow: The correct flow is for Redis updates to be driven by Kafka consumers, not clients directly mutating Redis. This ensures durability and stream replay-ability. Your initial flow missed this.
• Unnecessary Offline Aggregation: You suggested hourly aggregation jobs even though Redis ZSET already supports O(log N) insertion and ranking in real-time. Avoid adding unnecessary offline compute unless justified (e.g., cold recovery, analytics).
• GET Time Complexity Mischaracterization: You noted GET from Redis as O(logN), which is slightly misleading — Redis ZRANK, ZSCORE, ZRANGE for top-K are amortized O(1–logN), so be more precise to avoid undermining your argument.

Overall Assessment

Xi demonstrated strong fundamentals in large-scale system design, with solid progressions from APIs to data flow to storage and resilience. The biggest growth opportunity is around scoping and alignment early on, and precision in API and data structure usage (especially for Redis and Kafka).

You’re in a good position to succeed with a bit more polish on:

• Scoping via assumption-checking
• Core contract correctness (APIs, data flows)
• Load pattern sensitivity (hot keys, cardinality)

‍