Projektoni një leaderboard në kohë reale për miliona lojtarë

Question

IT Interview Practice · Accepted Answer

**Përdorni një Redis sorted set (ZSET) të indeksuar sipas score-it: rank dhe top-N bëhen operacione të integruara O(log N), kështu që kurrë nuk renditni miliona rreshta për çdo request.** Një ZSET i mban anëtarët të renditur sipas score-it automatikisht; kjo është saktësisht ajo çka është një leaderboard.

## Arkitektura

```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)
```

## Si funksionon

- **ZADD** bën upsert të score-it të një lojtari në O(log N). Redis e mban renditjen përmes një **skip list**, kështu që nuk nevojitet re-sort.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` kthen top 100 në O(log N + 100).
- **Rank-u yt**: `ZREVRANK board user` jep pozicionin 0-based; **around-me** është `ZREVRANGE rank-5 rank+5` — pjesa e lojtarëve pranë teje.
- **Durability**: Redis është in-memory. Aktivizoni **AOF** (append-only file) për replay, dhe pasqyroni score-t në mënyrë asinkrone te **Postgres** si sistemi i vërtetë i regjistrimit, kështu që një humbje e Redis është e rikuperueshme.

## Sharding për miliona përdorues

Një ZSET mban dhjetëra miliona anëtarë pa problem (memory-bound, ~100MB për 1M hyrje). Përtej kësaj, ose për shkallë globale, **shard sipas range-it të score-it** (0–1k, 1k–10k…) që çdo shard të jetë një brez i vazhdueshëm — një top-N global lexon vetëm shard-in e sipërm. Shmangni sharding sipas hash-it të përdoruesit: rikombinimi i rank-eve nëpër shards të rastësishëm është i shtrenjtë.

## Këndvështrimi i intervistës

Intervistuesi dëshiron t'ju shohë të **kapeni pas strukturës së duhur të të dhënave** në vend të `ORDER BY score LIMIT 100` në SQL (që bën re-sort në çdo goditje dhe vdes nën ngarkesë shkrimi). Përgjigjet e mira emërtojnë ZSET; përgjigjet e shkëlqyera mbulojnë **around-me queries, barazimet, persistencën, dhe strategjinë e shard-it**. Një kurth klasik: harresa se Redis është volatil dhe trajtimi i tij si burimi i së vërtetës — një restart e fshin board-in nëse nuk ekziston AOF/RDB ose një DB mirror.

## Kompromiset & gabimet

- **Barazime.** Score-t e barabartë renditen leksikografikisht sipas anëtarit, që duket i rastësishëm. Kodoni një tiebreaker në score (p.sh. `score * 1e13 - timestamp`) që arritësit më të hershëm të renditen më lart.
- **Hot key.** Një ZSET i vetëm global është një key në një shard — një write hotspot. Buffer/batch `ZADD`-et, ose përdorni board-e të grupuara sipas kohës (ditore/javore) për të shpërndarë ngarkesën.
- **Konsistenca.** Leximet mund të vonojnë DB mirror-in asinkron me sekonda — në rregull për leaderboards, jo për pagesa; rakordoni nga Postgres para se të jepni çmime.
- **Kosto memorie.** Miliona anëtarë kushtojnë RAM të vërtetë; skadoni board-et sezonalë me TTL.
- **Kur jo:** një leaderboard prej disa mijë i rifreskuar çdo minutë është në rregull si një cached SQL query — Redis ZSET shkëlqen kur shkrimet janë të vazhdueshme dhe rank-u duhet të jetë i menjëhershëm.

Arkitektura

Si funksionon

Sharding për miliona përdorues

Këndvështrimi i intervistës

Kompromiset & gabimet

Pyetje të ngjashme