millions of players కోసం ఒక real-time leaderboard ను design చేయండి

Question

IT Interview Practice · Accepted Answer

**score ద్వారా keyed అయిన ఒక Redis sorted set (ZSET) వాడండి: rank మరియు top-N O(log N) built-in operations అవుతాయి, కాబట్టి మీరు ఒక్కో request కి millions of 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 ను maintain చేస్తుంది, కాబట్టి re-sort అవసరం లేదు.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` O(log N + 100) లో top 100 ను return చేస్తుంది.
- **Your 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) ను enable చేసి, scores ను true system of record గా **Postgres** కి asynchronously mirror చేయండి, తద్వారా ఒక Redis loss recoverable.

## millions of user కోసం Sharding

ఒక ZSET tens of millions of members ను బాగానే కలిగి ఉంటుంది (memory-bound, 1M entries కి ~100MB). దాని దాటి, లేదా global scale కోసం, **score range ద్వారా shard చేయండి** (0–1k, 1k–10k…) తద్వారా ప్రతి shard ఒక contiguous band — ఒక global top-N top shard ను మాత్రమే read చేస్తుంది. 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** ను cover చేస్తాయి. Classic ఉచ్చు: Redis volatile అని మర్చిపోయి దాన్ని source of truth గా భావించడం — AOF/RDB లేదా DB mirror లేకపోతే ఒక restart board ను తుడిచేస్తుంది.

## ట్రేడ్-ఆఫ్‌లు & వైఫల్యాలు

- **Ties.** సమాన scores member ను lexicographically order చేస్తాయి, ఇది random గా కనిపిస్తుంది. score లోకి ఒక tiebreaker ను encode చేయండి (ఉదా. `score * 1e13 - timestamp`) తద్వారా ముందుగా సాధించినవారు ఎక్కువ 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 కి కాదు; prizes ఇచ్చే ముందు Postgres నుండి reconcile చేయండి.
- **Memory cost.** Millions of members నిజమైన RAM ఖర్చు చేస్తాయి; seasonal boards ను TTLs తో expire చేయండి.
- **ఎప్పుడు కాదు:** ప్రతి నిమిషం refresh అయ్యే కొన్ని వేల leaderboard ఒక cached SQL query గా బాగుంటుంది — writes నిరంతరం మరియు rank తక్షణం కావాల్సినప్పుడు Redis ZSET మెరుస్తుంది.

ఆర్కిటెక్చర్

ఇది ఎలా పనిచేస్తుంది

millions of user కోసం Sharding

ఇంటర్వ్యూ దృక్కోణం

ట్రేడ్-ఆఫ్‌లు & వైఫల్యాలు

సంబంధిత ప్రశ్నలు