С какими сервисами сетевых механик, например лидербордами, вы работали

Что проверяют

Работали ли вы с серверной стороной игровых механик или только показывали готовую таблицу на экране. Лидерборд выглядит простым до первого вопроса про место конкретного игрока, поэтому по ответу видно, доводили ли вы такой сервис до живых игроков.

Как отвечать

Скажите, с какой стороны заходили: готовый бэкенд игровой платформы или свой сервис на ASP.NET Core. Дальше разберите механику по частям:

• что считаем. Лучший результат за сезон, а не последний. Срезы: общий, среди друзей, по региону. Окно вокруг игрока важнее топа, человеку интересны соседи, а не первая десятка;
• хранение. Отсортированное множество в памяти, например в Redis, отдаёт место и окно быстро, а база остаётся источником правды. Считать позицию сортировкой всей таблицы на каждый заход нельзя, это самая частая ошибка такого дизайна;
• запись. Результаты приходят пиками на релизе и в конце сезона, помогает буферизация и запись пачками, а повторная отправка закрывается ключом идемпотентности;
• доверие. Клиент подделывают всегда. Результат либо пересчитывается на сервере, либо подписывается и проверяется на правдоподобие, а подозрительные значения уезжают в лог для разбора;
• сезоны. Архив прошлого периода, награды, чистая таблица на старте нового.

Где спотыкаются

Отвечают запросом с сортировкой и ограничением. Для топа этого хватает, но вопрос про место игрока из середины и про частые обновления такое решение ломает мгновенно.

Второе: забывают про читеров. Любое число, посчитанное на клиенте и принятое сервером как есть, окажется в таблице первым, и пострадает не архитектура, а интерес к игре.

Третье: рассказывают про клиентскую часть, хотя спрашивают про сервис. Если бэкенд делала другая команда, честнее сказать это и рассказать своё: протокол обмена, обработку сетевых ошибок, кэш и поведение таблицы при отсутствии связи.