Σχεδιάστε ένα real-time leaderboard για εκατομμύρια παίκτες

Question

IT Interview Practice · Accepted Answer

**Χρησιμοποιήστε ένα Redis sorted set (ZSET) με κλειδί το score: το rank και το top-N γίνονται O(log N) built-in operations, οπότε ποτέ δεν ταξινομείτε εκατομμύρια rows ανά request.** Ένα ZSET κρατά τα members ταξινομημένα κατά 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** κάνει upsert το score ενός παίκτη σε O(log N). Το Redis διατηρεί τη σειρά μέσω μιας **skip list**, οπότε δεν χρειάζεται re-sort.
- **Top-N**: το `ZREVRANGE board 0 99 WITHSCORES` επιστρέφει τους top 100 σε O(log N + 100).
- **Το rank σου**: το `ZREVRANK board user` δίνει τη 0-based θέση· το **around-me** είναι `ZREVRANGE rank-5 rank+5` — το κομμάτι των παικτών κοντά σας.
- **Durability**: το Redis είναι in-memory. Ενεργοποιήστε το **AOF** (append-only file) για replay, και ασύγχρονα καθρεφτίστε τα scores στην **Postgres** ως το αληθινό system of record, ώστε μια απώλεια Redis να είναι ανακτήσιμη.

## Sharding για εκατομμύρια χρήστες

Ένα ZSET κρατά δεκάδες εκατομμύρια members μια χαρά (memory-bound, ~100MB για 1M entries). Πέρα από αυτό, ή για global κλίμακα, κάντε **shard κατά score range** (0–1k, 1k–10k…) ώστε κάθε shard να είναι μια συνεχόμενη ζώνη — ένα global top-N διαβάζει μόνο το top shard. Αποφύγετε το sharding κατά user hash: ο επανασυνδυασμός ranks πέρα από τυχαία shards είναι ακριβός.

## Οπτική συνέντευξης

Ο συνεντευκτής θέλει να σας δει να **καταφεύγετε στη σωστή δομή δεδομένων** αντί για `ORDER BY score LIMIT 100` σε SQL (που κάνει re-sort σε κάθε hit και πεθαίνει κάτω από write load). Καλές απαντήσεις κατονομάζουν ZSET· εξαιρετικές απαντήσεις καλύπτουν **around-me queries, ισοπαλίες, persistence, και shard strategy**. Μια κλασική παγίδα: να ξεχνάτε ότι το Redis είναι volatile και να το αντιμετωπίζετε ως την πηγή αλήθειας — ένα restart σβήνει το board εκτός αν υπάρχει AOF/RDB ή DB mirror.

## Trade-offs & αποτυχία

- **Ισοπαλίες.** Ίσα scores ταξινομούνται λεξικογραφικά κατά member, που φαίνεται τυχαίο. Κωδικοποιήστε ένα tiebreaker στο score (π.χ. `score * 1e13 - timestamp`) ώστε οι νωρίτεροι επιτυχόντες να κατατάσσονται ψηλότερα.
- **Hot key.** Ένα μοναδικό global ZSET είναι ένα key σε ένα shard — ένα write hotspot. Κάντε buffer/batch τα `ZADD`, ή χρησιμοποιήστε time-bucketed boards (ημερήσια/εβδομαδιαία) για να απλώσετε το load.
- **Consistency.** Τα reads μπορεί να υστερούν από το async DB mirror κατά δευτερόλεπτα — εντάξει για leaderboards, όχι για πληρωμές· κάντε reconcile από την Postgres πριν απονείμετε βραβεία.
- **Κόστος μνήμης.** Εκατομμύρια members κοστίζουν πραγματική RAM· λήξτε εποχιακά boards με TTLs.
- **Πότε όχι:** ένα leaderboard μερικών χιλιάδων που ανανεώνεται κάθε λεπτό είναι μια χαρά ως cached SQL query — το Redis ZSET λάμπει όταν τα writes είναι συνεχή και το rank πρέπει να είναι ακαριαίο.

Αρχιτεκτονική

Πώς λειτουργεί

Sharding για εκατομμύρια χρήστες

Οπτική συνέντευξης

Trade-offs & αποτυχία

Σχετικές ερωτήσεις