மில்லியன் கணக்கான players-க்கு ஒரு real-time leaderboard-ஐ வடிவமைக்கவும்

Question

IT Interview Practice · Accepted Answer

**score-ஆல் keyed செய்யப்பட்ட ஒரு Redis sorted set (ZSET) பயன்படுத்துங்கள்: rank மற்றும் top-N ஆகியவை O(log N) built-in operations ஆகின்றன, எனவே நீங்கள் ஒருபோதும் ஒரு request-க்கு மில்லியன் கணக்கான rows-ஐ sort செய்வதில்லை.** ஒரு ZSET members-ஐ score-ஆல் தானாக ordered-ஆக வைத்திருக்கிறது; ஒரு leaderboard என்பது சரியாக அதுவே.

## கட்டமைப்பு

```text
Game svc ──ZADD score──▶ Redis ZSET (sorted by score) ──ZREVRANGE 0 99──▶ Top-100 API
                              │
                              ├─ ZREVRANK user ─▶ "your rank" (around-me: rank±5)
                              └─ AOF/RDB + async ─▶ Postgres (durable source of truth)
```

## எப்படி வேலை செய்கிறது

- **ZADD** ஒரு player-இன் score-ஐ O(log N)-இல் upsert செய்கிறது. Redis ஒரு **skip list** மூலம் order பராமரிக்கிறது, எனவே re-sort தேவையில்லை.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` top 100-ஐ O(log N + 100)-இல் திருப்புகிறது.
- **உங்கள் rank**: `ZREVRANK board user` 0-based position தருகிறது; **around-me** என்பது `ZREVRANGE rank-5 rank+5` — உங்களுக்கு அருகில் உள்ள players-இன் slice.
- **Durability**: Redis in-memory. replay-க்கு **AOF** (append-only file) இயக்கி, scores-ஐ உண்மையான system of record ஆக **Postgres**-க்கு asynchronous-ஆக mirror செய்யுங்கள், இதனால் ஒரு Redis இழப்பு மீட்டெடுக்கக்கூடியது.

## மில்லியன் கணக்கான users-க்கு Sharding

ஒரு ZSET பத்து மில்லியன் கணக்கான members-ஐ நன்றாக வைத்திருக்கிறது (memory-bound, 1M entries-க்கு ~100MB). அதற்கு அப்பால், அல்லது global scale-க்கு, **score range மூலம் shard செய்யுங்கள்** (0–1k, 1k–10k…) இதனால் ஒவ்வொரு shard-ம் ஒரு contiguous band — ஒரு global top-N top shard-ஐ மட்டும் படிக்கிறது. user hash மூலம் sharding-ஐத் தவிர்க்கவும்: random shards முழுவதும் ranks-ஐ மீண்டும் இணைப்பது விலையுயர்ந்தது.

## நேர்காணல் கண்ணோட்டம்

SQL மீது `ORDER BY score LIMIT 100`-க்குப் பதிலாக (ஒவ்வொரு hit-இலும் re-sort செய்து write load-இல் இறக்கிறது) **சரியான data structure-ஐ நோக்குவதை** நேர்காணல் செய்பவர் பார்க்க விரும்புகிறார். நல்ல பதில்கள் ZSET குறிப்பிடுகின்றன; சிறந்த பதில்கள் **around-me queries, ties, persistence, மற்றும் shard strategy**-ஐ உள்ளடக்குகின்றன. ஒரு classic பொறி: Redis volatile என்பதை மறந்து அதை source of truth ஆகக் கருதுவது — AOF/RDB அல்லது ஒரு DB mirror இல்லாவிட்டால் ஒரு restart board-ஐ அழிக்கிறது.

## சமரசங்களும் பிழைகளும்

- **Ties.** சம scores members-ஐ lexicographically order செய்கின்றன, அது random-ஆகத் தெரிகிறது. score-க்குள் ஒரு tiebreaker-ஐ encode செய்யுங்கள் (எ.கா. `score * 1e13 - timestamp`) இதனால் முந்தைய achievers உயர்ந்த rank பெறுகிறார்கள்.
- **Hot key.** ஒரே global ZSET ஒரு shard மீது ஒரு key — ஒரு write hotspot. `ZADD`s-ஐ buffer/batch செய்யுங்கள், அல்லது load-ஐப் பரப்ப time-bucketed boards (daily/weekly) பயன்படுத்துங்கள்.
- **Consistency.** Reads async DB mirror-ஐ வினாடிகள் பின்தொடரலாம் — leaderboards-க்கு பரவாயில்லை, payouts-க்கு அல்ல; பரிசுகளை வழங்குவதற்கு முன் Postgres-இலிருந்து reconcile செய்யுங்கள்.
- **Memory cost.** மில்லியன் கணக்கான members உண்மையான RAM செலவழிக்கின்றன; seasonal boards-ஐ TTLs உடன் expire செய்யுங்கள்.
- **எப்போது இல்லை:** ஒவ்வொரு நிமிடமும் refresh செய்யப்படும் சில ஆயிரம் leaderboard ஒரு cached SQL query ஆக நன்றாக இருக்கும் — writes நிலையானதாக இருந்து rank உடனடியாக இருக்க வேண்டும்போது Redis ZSET பிரகாசிக்கிறது.

கட்டமைப்பு

எப்படி வேலை செய்கிறது

மில்லியன் கணக்கான users-க்கு Sharding

நேர்காணல் கண்ணோட்டம்

சமரசங்களும் பிழைகளும்

தொடர்புடைய கேள்விகள்