Suunnittele reaaliaikainen tulostaulu (leaderboard) miljoonille pelaajille

Question

IT Interview Practice · Accepted Answer

**Käytä Redisin lajiteltua joukkoa (sorted set, ZSET) avainnettuna pisteillä: sijoituksesta ja top-N:stä tulee O(log N) valmiita operaatioita, joten et koskaan lajittele miljoonia rivejä per pyyntö.** ZSET pitää jäsenet järjestyksessä pisteiden mukaan automaattisesti; juuri sitä tulostaulu on.

## Arkkitehtuuri

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

## Miten se toimii

- **ZADD** upsertaa pelaajan pisteet O(log N):ssä. Redis ylläpitää järjestystä **skip listillä**, joten uudelleenlajittelua ei tarvita.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` palauttaa top 100 O(log N + 100):ssa.
- **Oma sijoitus**: `ZREVRANK board user` antaa 0-pohjaisen position; **around-me** on `ZREVRANGE rank-5 rank+5` — siivu pelaajista lähelläsi.
- **Kestävyys**: Redis on muistissa. Ota käyttöön **AOF** (append-only file) toistoa varten, ja peilaa pisteet asynkronisesti **Postgresiin** todellisena system of recordina, jotta Redis-menetys on palautettavissa.

## Sharding miljoonille käyttäjille

Yksi ZSET pitää kymmeniä miljoonia jäseniä hyvin (muistirajoitteinen, ~100 MB per 1M merkintää). Sen yli, tai globaalia mittakaavaa varten, **shardaa pisterangen mukaan** (0–1k, 1k–10k…), jotta jokainen shard on yhtenäinen kaista — globaali top-N lukee vain top-shardin. Vältä shardausta käyttäjä-hashilla: sijoitusten uudelleenyhdistäminen satunnaisten shardien yli on kallista.

## Haastattelunäkökulma

Haastattelija haluaa nähdä sinun **tarttuvan oikeaan tietorakenteeseen** eikä `ORDER BY score LIMIT 100`:iin SQL:ssä (joka lajittelee uudelleen joka osumalla ja kuolee kirjoituskuorman alla). Hyvät vastaukset nimeävät ZSETin; loistavat kattavat **around-me-kyselyt, tasapelit, pysyväistallennuksen ja shard-strategian**. Klassinen ansa: unohtaa, että Redis on volatiili, ja kohdella sitä totuuden lähteenä — uudelleenkäynnistys pyyhkii taulun, ellei AOF/RDB tai DB-peili ole olemassa.

## Kompromissit ja virhetilanteet

- **Tasapelit.** Yhtä suuret pisteet järjestyvät jäsenen mukaan leksikografisesti, mikä näyttää satunnaiselta. Koodaa tiebreaker pisteeseen (esim. `score * 1e13 - timestamp`), jotta aikaisemmat saavuttajat sijoittuvat korkeammalle.
- **Kuuma avain.** Yksittäinen globaali ZSET on yksi avain yhdellä shardilla — kirjoitus-hotspot. Puskuroi/batch-tee `ZADD`:it, tai käytä aikaslotitettuja tauluja (päivittäinen/viikoittainen) kuorman levittämiseksi.
- **Konsistenssi.** Lukemiset voivat laahata async-DB-peiliä sekunteja — ok tulostauluille, ei maksuille; täsmäytä Postgresista ennen palkintojen jakamista.
- **Muistikustannus.** Miljoonat jäsenet maksavat todellista RAM:ia; vanhenna kausikohtaiset taulut TTL:illä.
- **Milloin ei:** muutaman tuhannen tulostaulu, joka päivittyy minuutin välein, on ok cachattuna SQL-kyselynä — Redisin ZSET loistaa, kun kirjoitukset ovat jatkuvia ja sijoituksen on oltava välitön.

Arkkitehtuuri

Miten se toimii

Sharding miljoonille käyttäjille

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset