ออกแบบ leaderboard แบบ real-time สำหรับผู้เล่นหลายล้านคน

Question

IT Interview Practice · Accepted Answer

**ใช้ Redis sorted set (ZSET) ที่ใช้ score เป็น key: rank และ top-N กลายเป็น operation built-in แบบ O(log N) ดังนั้นคุณไม่เคย sort หลายล้าน row ต่อ request** ZSET เก็บ member เรียงตาม 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` — slice ของผู้เล่นที่อยู่ใกล้คุณ
- **Durability**: Redis อยู่ใน memory เปิด **AOF** (append-only file) สำหรับ replay และ mirror score ไปยัง **Postgres** แบบ asynchronous ในฐานะ system of record ที่แท้จริง เพื่อให้การเสีย Redis กู้คืนได้

## Sharding สำหรับผู้ใช้หลายล้าน

ZSET เดียวเก็บ member ได้หลายสิบล้านสบาย (จำกัดด้วย memory ราว 100MB ต่อ 1M entry) เกินกว่านั้น หรือสำหรับ scale ระดับ global ให้ **shard ตาม score range** (0–1k, 1k–10k…) เพื่อให้แต่ละ shard เป็นแถบต่อเนื่อง — top-N ระดับ global อ่านเฉพาะ shard บนสุด หลีกเลี่ยงการ shard ตาม user hash: การรวม rank กลับข้าม shard สุ่มนั้นแพง

## มุมมองการสัมภาษณ์

ผู้สัมภาษณ์อยากเห็นคุณ **ไขว่คว้าหา data structure ที่ถูกต้อง** แทน `ORDER BY score LIMIT 100` บน SQL (ซึ่ง re-sort ทุกครั้งที่ถูกเรียกและตายภายใต้ write load) คำตอบที่ดีระบุ ZSET คำตอบที่เยี่ยมครอบคลุม **around-me query, ties, persistence และกลยุทธ์ shard** กับดักคลาสสิก: ลืมว่า Redis volatile และปฏิบัติต่อมันเป็น source of truth — การ restart ล้างกระดานเว้นแต่มี AOF/RDB หรือ DB mirror

## ข้อแลกเปลี่ยน & failure

- **Ties** score เท่ากันเรียงตาม member แบบ lexicographic ซึ่งดูสุ่ม encode tiebreaker ลงใน score (เช่น `score * 1e13 - timestamp`) เพื่อให้ผู้ที่ทำได้ก่อน rank สูงกว่า
- **Hot key** ZSET global เดียวคือ key เดียวบน shard เดียว — write hotspot buffer/batch `ZADD` หรือใช้กระดานแบบแบ่งช่วงเวลา (รายวัน/รายสัปดาห์) เพื่อกระจาย load
- **Consistency** การอ่านอาจล่าช้ากว่า DB mirror ที่ async หลายวินาที — โอเคสำหรับ leaderboard ไม่โอเคสำหรับการจ่ายเงิน กระทบยอดจาก Postgres ก่อนมอบรางวัล
- **ต้นทุน memory** member หลายล้านกิน RAM จริง expire กระดานตามฤดูกาลด้วย TTL
- **เมื่อไม่ควรใช้:** leaderboard ไม่กี่พันที่ refresh ทุกนาทีก็โอเคในฐานะ cached SQL query — Redis ZSET เปล่งประกายเมื่อการเขียนคงที่และ rank ต้องทันที

สถาปัตยกรรม

หลักการทำงาน

Sharding สำหรับผู้ใช้หลายล้าน

มุมมองการสัมภาษณ์

ข้อแลกเปลี่ยน & failure

คำถามที่เกี่ยวข้อง