Реализация лидерборда пользователей для геймификации мобильного приложения
Лидерборд звучит просто — отсортировать пользователей по очкам. Но когда пользователей тысячи, этот простой ORDER BY score DESC начинает убивать базу данных. А когда нужен real-time ранг текущего пользователя среди миллиона — это уже Redis и специальные структуры данных.
Архитектура для разных масштабов
До 10 000 пользователей: PostgreSQL + RANK() / DENSE_RANK() window function. Запрос с пагинацией работает быстро даже без специальных индексов. Кешируем топ-100 в Redis с TTL 5 минут.
10 000 – 1 000 000 пользователей: Redis Sorted Set (ZADD, ZRANK, ZREVRANK, ZREVRANGE). Добавление очков: ZADD leaderboard:global NX <score> <user_id> или ZINCRBY leaderboard:global <delta> <user_id>. Получение ранга пользователя: ZREVRANK leaderboard:global <user_id> — O(log N). Топ-100: ZREVRANGE leaderboard:global 0 99 WITHSCORES — O(log N + 100). Это работает без деградации даже на миллионе пользователей.
Миллионы пользователей: шардирование Redis Sorted Set по временным периодам и регионам. Глобальный лидерборд превращается в недостижимую цель для большинства — демотивирует. Лучше сегментировать.
Временные периоды лидерборда
Глобальный «all time» — для топ-игроков. Еженедельный и ежемесячный — для всех остальных. Сброс в начале периода: не удаляем данные, архивируем. Пользователь должен видеть свои прошлые результаты.
Реализация сброса: отдельный ключ для каждого периода leaderboard:weekly:2025-W13, leaderboard:monthly:2025-03. По истечении периода создаём новый ключ — старый остаётся для истории. TTL на старые ключи: 30 дней для недельных, 90 для месячных.
Ранжирование «вокруг меня»
Самый полезный вид лидерборда для среднего пользователя. Не «топ-100», а «ты на месте 4573, вот 5 человек выше и 5 ниже». Мотивирует тех, кто никогда не войдёт в топ.
Реализация на Redis: ZREVRANK для получения ранга пользователя, затем ZREVRANGE(rank-5, rank+5) для соседних позиций. Дополнительный запрос к PostgreSQL для получения display name и аватара по user_id из результата.
Социальные лидерборды
Лидерборд среди друзей — часто мотивирует сильнее, чем глобальный. Реализация сложнее: нет смысла в глобальном sorted set для списка из 50 друзей.
Вариант 1: при открытии экрана делаем запрос к PostgreSQL: SELECT user_id, score FROM user_scores WHERE user_id IN (:friends_list) ORDER BY score DESC. Работает при небольшом числе друзей.
Вариант 2: отдельный sorted set для каждого пользователя leaderboard:user:<user_id>:friends — обновляем при каждом изменении очков любого друга. Дороже по памяти Redis, зато мгновенное чтение.
Отображение и UX
Подсветка позиции текущего пользователя в списке — обязательно. Анимированное обновление ранга при получении новых очков (ScrollTo + highlight). Стрелки роста/падения рядом с позицией — «ты вырос на 12 мест за сегодня». Историческая кривая ранга пользователя за период.
На Flutter: AnimatedList для smooth обновлений. На iOS: UITableView с performBatchUpdates. Не перезагружай весь список при обновлении — только изменившиеся ячейки.
Аватары в лидерборде — кешируй агрессивно. SDWebImage (iOS) / Glide (Android) / cached_network_image (Flutter) с disk cache. Не показывай лидерборд без имён и аватаров — только скелетон во время загрузки.
Ориентиры по срокам
Базовый лидерборд с недельным/месячным периодом и рангом пользователя — 2–3 дня (клиент) + 2–3 дня (бэкенд на Redis). С социальным лидербордом, «вокруг меня», историей рангов и real-time обновлениями — 1–2 недели. Стоимость рассчитывается индивидуально.