문제 12 — 랭킹/리더보드 자료구조와 저장 설계 (Sorted Set, 동점, 페이지네이션)

수백만 명이 참여하는 시즌 랭킹을 만든다. 플레이어 점수는 수시로 갱신되고, 클라이언트는 "전체 Top 100", "내 순위", "내 주변 순위(±5위)"를 빠르게 보고 싶어 한다. 다음에 답하라.

1. 점수가 바뀔 때마다 RDB에서 SELECT ... ORDER BY score로 순위를 계산하는 방식의 문제는 무엇인가? 왜 정렬된 자료구조(스킵 리스트/균형 트리 기반) 가 랭킹에 적합한지, 주요 연산의 시간복잡도와 함께 설명하라.

2. Redis Sorted Set(ZSET) 으로 리더보드를 구현한다면 어떤 명령으로 (a) 점수 갱신, (b) 내 점수/순위 조회, (c) Top N, (d) 내 주변 순위를 구현하는가? 각 연산의 대략적 복잡도도 적어라.

3. 동점(tie) 처리: 점수가 같을 때 순위를 어떻게 안정적으로 정하는가? "점수 + 시간(먼저 도달한 사람이 위)"처럼 보조 기준을 하나의 정렬 키에 인코딩하는 방법을 예로 들어라. 또 대규모에서 페이지네이션(예: 50,000위부터 100개)이 왜 비싸질 수 있고 어떻게 완화하는가?

4. 영속화·정합성·확장: 인메모리 랭킹(Redis)과 원본 DB의 일관성을 어떻게 맞추는가(갱신 흐름, 시즌 마감 스냅샷, 장애 복구)? 수천만 규모에서 단일 ZSET의 한계와 샤딩/근사 랭킹(approximate rank) 같은 대안도 논하라.