დააპროექტეთ real-time leaderboard მილიონობით მოთამაშისთვის

Question

IT Interview Practice · Accepted Answer

**გამოიყენეთ Redis sorted set (ZSET), დაფუძნებული score-ზე: rank და top-N ხდება O(log N) ჩაშენებული ოპერაცია, ასე რომ არასდროს ახარისხებთ მილიონობით მწკრივს თითო request-ზე.** ZSET წევრებს score-ით ავტომატურად ალაგებს; ზუსტად ეს არის 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** მოთამაშის score-ს upsert-ს O(log N)-ში. Redis წესრიგს **skip list**-ით ინახავს, ასე რომ ხელახალი დახარისხება არ სჭირდება.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` აბრუნებს top 100-ს O(log N + 100)-ში.
- **შენი rank**: `ZREVRANK board user` აძლევს 0-ზე დაფუძნებულ პოზიციას; **around-me** არის `ZREVRANGE rank-5 rank+5` — შენს გვერდით მდგომი მოთამაშეების ნაჭერი.
- **Durability**: Redis in-memory-ია. ჩართეთ **AOF** (append-only file) replay-ისთვის და ასინქრონულად ასახეთ score-ები **Postgres**-ში, როგორც ნამდვილი system of record, ასე რომ Redis-ის დაკარგვა აღდგენადია.

## Sharding მილიონობით მომხმარებლისთვის

ერთი ZSET ათეულ მილიონობით წევრს კარგად იტევს (memory-bound, ~100MB 1M ჩანაწერზე). ამის მიღმა, ან გლობალური მასშტაბისთვის, **shard გააკეთეთ score range-ით** (0–1k, 1k–10k…), რომ თითო shard მიმდევრობითი ზოლი იყოს — გლობალური top-N მხოლოდ top shard-ს კითხულობს. მოერიდეთ user hash-ით sharding-ს: rank-ების ხელახლა შეერთება შემთხვევით shard-ებზე ძვირია.

## ინტერვიუს პერსპექტივა

ინტერვიუერს სურს დაინახოს, რომ **სწორ მონაცემთა სტრუქტურამდე მიდიხართ** და არა `ORDER BY score LIMIT 100`-ამდე SQL-ზე (რომელიც ყოველ ჯერზე ხელახლა ახარისხებს და write load-ის ქვეშ კვდება). კარგი პასუხები ასახელებს ZSET-ს; შესანიშნავი პასუხები ფარავს **around-me query-ებს, ტოლობებს, persistence-ს და shard სტრატეგიას**. კლასიკური ხაფანგი: დავიწყება, რომ Redis არასტაბილურია და მისი source of truth-ად მიჩნევა — restart board-ს შლის, თუ AOF/RDB ან DB mirror არ არსებობს.

## ტრეიდ-ოფები და ჩავარდნები

- **ტოლობები.** თანაბარი score-ები წევრს ლექსიკოგრაფიულად ალაგებს, რაც შემთხვევით გამოიყურება. ჩააქციეთ tiebreaker score-ში (მაგ. `score * 1e13 - timestamp`), რომ ადრინდელი მიღწევის მქონეები მაღლა იყვნენ.
- **Hot key.** ერთი გლობალური ZSET არის ერთი გასაღები ერთ shard-ზე — write hotspot. ბუფერი/batch გაუკეთეთ `ZADD`-ებს, ან გამოიყენეთ time-bucketed board-ები (დღიური/კვირეული) load-ის გასანაწილებლად.
- **Consistency.** read-ები ასინქრონულ DB mirror-ს შეიძლება წამებით ჩამორჩნენ — leaderboard-ისთვის ნორმალურია, გადახდებისთვის — არა; შეაჯერეთ Postgres-იდან პრიზების დაჯილდოებამდე.
- **მეხსიერების ღირებულება.** მილიონობით წევრი ნამდვილ RAM-ს ხარჯავს; ვადა გაუსვით სეზონურ board-ებს TTL-ებით.
- **როდის არა:** რამდენიმე ათასიანი leaderboard, განახლებული ყოველ წუთს, კარგია დაქეშილ SQL query-ად — Redis ZSET ბრწყინავს, როცა write-ები მუდმივია და rank მყისვე უნდა იყოს.

არქიტექტურა

როგორ მუშაობს

Sharding მილიონობით მომხმარებლისთვის

ინტერვიუს პერსპექტივა

ტრეიდ-ოფები და ჩავარდნები

დაკავშირებული კითხვები