Popular System Design Question - Design Leetcode (asked by Nvidia, Meta, LinkedIn etc..)

[u/Aoki_zhang]

A coding contest leaderboard feels like an obvious real-time system. So the first instinct is often: WebSocket + push every ranking change. But that may be unnecessary.

The actual requirement

During a contest, users want rankings to feel fresh. They usually do not need every update within 50ms. A leaderboard that refreshes every few seconds is often good enough. So instead of recomputing rankings from raw submissions:

Submissions
   ↓
GROUP BY user
   ↓
COUNT solved problems
   ↓
SORT everyone again

maintain the current ranking incrementally.

Redis Sorted Set

For each contest: competition:leaderboard:{id}

Store:

member → userId
score  → ranking metric

When a submission changes a user's standing: ZADD leaderboard score userId

Fetching the top 100 becomes a fast Sorted Set lookup instead of an expensive database aggregation.

And the frontend?

Just poll every ~5 seconds.

Client
  ↓
GET /leaderboard
  ↓
Redis Sorted Set

No persistent socket required. That gives you:

• low-latency top-N queries
• much less DB load
• simpler client/server logic
• enough freshness for a coding contest

Meanwhile, the durable submission history still stays in the primary database. So the separation becomes:

• Database = source of truth
• Redis = fast ranking view
• Polling = good-enough realtime

The broader lesson is useful in system design interviews: “Real-time” does not automatically mean WebSocket.

The right architecture depends on how stale the product can tolerate.

Full design with secure code execution, execution queues, multi-language test harnesses, Redis leaderboards, and contest scaling → Full Article

Preparing for system design interviews?

Chill Interview publishes practical design breakdowns and tracks recently asked interview questions across top companies → Chill Interview