લાખો 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 order ને **skip list** દ્વારા જાળવે છે, તેથી કોઈ re-sort જરૂરી નથી.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` top 100 ને O(log N + 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 ને asynchronously **Postgres** પર true system of record તરીકે mirror કરો, જેથી Redis loss recoverable રહે.

## લાખો 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 તરફ પહોંચતા** જોવા માંગે છે. Good answers ZSET નું નામ આપે છે; great answers **around-me queries, ties, persistence, અને shard strategy** આવરી લે છે. એક classic trap: Redis volatile છે તે ભૂલવું અને તેને source of truth ગણવી — AOF/RDB કે DB mirror ન હોય તો restart board ને wipe કરે છે.

## Trade-offs અને failure

- **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 થી સેકન્ડ્સ lag કરી શકે — leaderboards માટે ઠીક, payouts માટે નહીં; prizes આપતાં પહેલાં Postgres થી reconcile કરો.
- **Memory cost.** લાખો members real RAM ખર્ચે છે; seasonal boards ને TTLs વડે expire કરો.
- **ક્યારે ન કરવું:** દર મિનિટે refresh થતું થોડા હજારનું leaderboard cached SQL query તરીકે ઠીક છે — Redis ZSET ત્યારે ચમકે છે જ્યારે writes સતત હોય અને rank instant હોવો જોઈએ.

આર્કિટેક્ચર

તે કેવી રીતે કામ કરે છે

લાખો users માટે Sharding

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure

સંબંધિત પ્રશ્નો