Designing a Live-Streaming Leaderboard System: From Redis ZSet to Real-Time Ranking at Scale

I. Why Leaderboards Are Harder Than They Look

A leaderboard looks like a "simple feature": sort users by tip amount, show the top 100. Many engineers' first instinct is "one ORDER BY and done."

But in a live-streaming context, the complexity explodes:

• Real-time: The moment a user sends a gift, the board must update instantly. More than 1-2 seconds of delay and users feel "I tipped but nothing happened."

• High concurrency: A hot room with tens of thousands of concurrent viewers can peak at thousands of writes per second.

• Multi-dimensional: Real-time, daily, weekly, monthly, and all-time boards coexist — plus creator-received boards, user-sent boards, contribution boards, and more.

• Massive data: With hundreds of millions of cumulative users, full sorting of the all-time board is impossible.

• Consistency: Rankings can't jump around; "I tipped but my rank dropped" must never happen.

A traditional SELECT ... ORDER BY ... LIMIT would melt your database in seconds. This article is about building a leaderboard around Redis Sorted Sets (ZSet) that handles billions of records with millisecond response.

II. Core Data Structure: Why Redis ZSet

2.1 What ZSet Is

Redis Sorted Set (ZSet) was practically built for leaderboards. Each element has two parts:

• member: usually the user ID

• score: usually the tip amount or contribution value

Internally it uses a skiplist + hash table, guaranteeing: always-ordered by score; O(log N) to insert, delete, or update a single element; O(log N + M) to query a rank range (top 100), where M is the number returned. Whether the board has 100 or 10 million entries, updating a score and fetching the top 100 are both fast.

2.2 Core Commands

# Increment a user's score (called on gift send), returns new score
ZINCRBY rank:gift:room:1001 520 "user:88888"

# Get top 100 (high to low), WITHSCORES returns scores too
ZREVRANGE rank:gift:room:1001 0 99 WITHSCORES

# Get a user's rank (high to low, 0-indexed)
ZREVRANK rank:gift:room:1001 "user:88888"

The whole loop — "user tips → board updates in real time → query rank" — comes down to ZINCRBY and ZREVRANGE/ZREVRANK.

2.3 Why Not Database Sorting

The conclusion is clear: use Redis ZSet for real-time reads/writes; the database handles persistence and reconciliation only.

III. Key Design: Time-Sharding and Multi-Dimensional Boards

Key naming directly determines maintainability. A good convention expresses "board type + dimension + time period":

rank:{type}:{dimension}:{objectId}:{period}

rank:gift:room:1001:realtime     # real-time gift board
rank:gift:room:1001:20261009     # daily board
rank:gift:anchor:88888:202610w41 # creator weekly board
rank:gift:anchor:88888:202610    # creator monthly board

The key to weekly/monthly boards is encoding the time period into the key. Each period is a separate ZSet; a new period automatically writes to a new key. On gift send, use pipeline to batch-update the real-time/daily/weekly/monthly boards and cut round-trips.

Time-sharding means keys accumulate, so set a sensible TTL per board (daily 7 days, weekly 5 weeks, monthly 13 months). Note: set TTL with a Lua script that checks "only if the key doesn't exist" — otherwise re-setting TTL after every ZINCRBY means active boards never expire.

IV. Real-Time Updates: Write Optimization Under Load

The naive approach is a direct ZINCRBY per gift. Fine for normal rooms, but top-creator PKs and large events can hit tens of thousands of writes per second, and the hot key becomes a bottleneck. Two directions:

Local aggregation + batch commit: For boards that don't need extreme real-time (weekly/monthly), aggregate in a 1-second window at the application layer, compressing tens of thousands of writes per second into one batch — Redis load drops sharply.

Hot-key sharding: Split one logical board into N physical shards, hash writes by user ID, and merge reads with ZUNIONSTORE. Suits write-heavy, read-light scenarios, paired with caching.

V. Read Optimization: TopN Caching and Pagination

Reads have a key trait: most people only look at the top few dozen. The top 100 barely changes within a second, so a two-level cache (local Caffeine + Redis) keeps 90%+ of reads local.

For "view ranks near me," don't allow infinite paging (deep pagination gets slower). The standard is full top 100 + a separate "Your rank: #5001" row.

One classic trick: ZSet breaks score ties by member lexicographic order, which violates "first come, first served." The fix is encoding a timestamp into the score — integer part for score, fractional part for a timestamp complement — so earlier tippers rank higher on ties.

VI. Persistence and Reconciliation: Redis Isn't the Source of Truth

Treating Redis as the sole data source is dangerous. The right architecture: Redis carries real-time reads/writes (display layer), the database logs every tip transaction (source of truth), and a scheduled reconciliation job recomputes the board from transactions to correct Redis drift. Even if Redis fails, you can rebuild from the log; settlement and rewards use the database aggregate.

VII. Settlement and Rewards: Consistency Above All

Weekly/monthly boards usually tie to rewards, so settlement consistency is critical: "freeze" the board at the cutoff; pay out based on the database aggregate; and make payouts idempotent using periodId + rank as a unique key, guaranteeing one reward per rank per period.

VIII. How Gift Assets Affect the Leaderboard Experience

No matter how good the backend is, what users ultimately see is "who sent what gift and ranks where." Here's a point backend engineers often miss: the gift icons and effects shown on the board directly influence tipping intent.

A well-designed board shows a user's highest-value gift icon next to their name, or adds exclusive effects around the top user. This requires gift assets to be: crisp at small sizes (32×32 / 48×48 px), stylistically unified across the whole board, and clearly tiered so high-value gifts are visually distinct from low-value ones.

Crisp gift icons

Unified visual style

Clear tiering

Resolution-adaptive

Leaderboards need resolution-adaptive, stylistically unified gift assets

In practice, mature platforms maintain a resolution-adaptive gift asset library, providing size-appropriate resources for leaderboards, chat bullets, and full-screen effects alike — keeping 48px icons crisp and full-screen animations smooth.

IX. Full Technology Stack Summary

X. Conclusion

The leaderboard is the classic "looks simple, hard to do well" module in live and social products. It tests not just ZSet fluency, but your command of high concurrency, cache consistency, reconciliation, and idempotent design.

And don't forget: technology serves the experience. No matter how elegant the architecture, blurry board icons and cheap gift effects won't make users want to climb the ranks. The backend ZSet and the frontend asset library together form an ecosystem that makes people "want to rank higher."

About Virtual Gift Asset Libraries

High-quality virtual gift assets are a crucial part of the live-streaming experience. A professional asset library provides resolution-adaptive resources for leaderboard icons, chat bullets, and full-screen effects, while keeping a unified design style and smooth animation performance — helping platforms maintain visual freshness.