Rancang leaderboard real-time untuk jutaan pemain

Question

IT Interview Practice · Accepted Answer

**Gunakan Redis sorted set (ZSET) yang di-key berdasarkan skor: rank dan top-N menjadi operasi bawaan O(log N), sehingga Anda tidak pernah menyortir jutaan baris per request.** Sebuah ZSET menjaga anggota terurut berdasarkan skor secara otomatis; itu persis apa itu leaderboard.

## Arsitektur

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

## Cara kerjanya

- **ZADD** meng-upsert skor pemain dalam O(log N). Redis memelihara urutan via **skip list**, jadi tidak perlu sortir ulang.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` mengembalikan top 100 dalam O(log N + 100).
- **Rank Anda**: `ZREVRANK board user` memberi posisi berbasis-0; **around-me** adalah `ZREVRANGE rank-5 rank+5` — irisan pemain di dekat Anda.
- **Durability**: Redis in-memory. Aktifkan **AOF** (append-only file) untuk replay, dan cerminkan skor secara asinkron ke **Postgres** sebagai sistem pencatat yang sebenarnya, sehingga kehilangan Redis dapat dipulihkan.

## Sharding untuk jutaan user

Satu ZSET menampung puluhan juta anggota dengan baik (dibatasi memori, ~100MB untuk 1 juta entri). Melampaui itu, atau untuk skala global, **shard berdasarkan range skor** (0–1k, 1k–10k…) sehingga setiap shard adalah pita kontigu — top-N global hanya membaca shard teratas. Hindari sharding berdasarkan hash pengguna: menggabungkan ulang rank antar shard acak itu mahal.

## Perspektif wawancara

Pewawancara ingin melihat Anda **meraih struktur data yang tepat** alih-alih `ORDER BY score LIMIT 100` di SQL (yang menyortir ulang setiap hit dan mati di bawah beban write). Jawaban baik menyebut ZSET; jawaban hebat mencakup **query around-me, seri (ties), persistensi, dan strategi shard**. Jebakan klasik: lupa Redis bersifat volatil dan memperlakukannya sebagai sumber kebenaran — sebuah restart menghapus board kecuali AOF/RDB atau cermin DB ada.

## Trade-off & kegagalan

- **Seri (ties).** Skor sama diurutkan berdasarkan anggota secara leksikografis, yang terlihat acak. Encode tiebreaker ke dalam skor (mis. `score * 1e13 - timestamp`) agar yang berprestasi lebih awal ranking-nya lebih tinggi.
- **Hot key.** Satu ZSET global adalah satu key di satu shard — hotspot write. Buffer/batch `ZADD`, atau gunakan board berbucket waktu (harian/mingguan) untuk menyebar beban.
- **Consistency.** Baca bisa tertinggal cermin DB asinkron selama beberapa detik — baik untuk leaderboard, tidak untuk pembayaran; rekonsiliasi dari Postgres sebelum memberi hadiah.
- **Biaya memori.** Jutaan anggota memakan RAM nyata; kedaluwarsakan board musiman dengan TTL.
- **Kapan tidak perlu:** leaderboard beberapa ribu yang di-refresh setiap menit cukup sebagai query SQL yang di-cache — ZSET Redis bersinar saat write konstan dan rank harus instan.

Arsitektur

Cara kerjanya

Sharding untuk jutaan user

Perspektif wawancara

Trade-off & kegagalan

Pertanyaan terkait