Российские технологии и цифровая экономика
ПоискRSS

Микросервисная архитектура ускорила запуск игровых механик Pari с года до недели

5 минут чтения

Как микросервисная архитектура помогла ускорить запуск игровых механик с года до недели

Меня зовут Илья, я руководитель направления геймификации в PARI. До перехода в компанию я развивал собственный бизнес в холдинге EXCORP.GG, где мы создавали игровые спецпроекты для EXTREMUM и CS.MONEY. Главная проблема такой модели заключалась в том, что каждый проект приходилось собирать практически с нуля. Он существовал несколько недель, завершался вместе с кампанией - и значительная часть наработок оказывалась невостребованной.

Со временем стало очевидно: отдельные игровые элементы эффективнее объединять в единую систему. Тогда они смогут усиливать друг друга, а команда - повторно использовать уже созданные решения. Так появилась идея платформы, которая превращает разрозненные активности в полноценный продукт. Я представил концепцию основателям и запустил LVL.IO - компанию, занимавшуюся разработкой такого решения.

Позднее я показал проект Ивану Бураченко, бывшему руководителю киберспортивного направления PARI. Концепция хорошо совпала с задачами компании: в 2022 году PARI заключила годовой контракт с BLAST - международной киберспортивной организацией, которая проводит турниры и другие события по Counter-Strike. Так я сначала стал партнёром и поставщиком технологии, а затем перешёл в PARI и продолжил развивать продукт уже внутри компании.

От отдельной акции к постоянной платформе

В 2022 году PARI PASS запускался как программа дополнительной мотивации за привычные действия. Пользователь делал ставку, получал PARI Coins и мог обменять их на фрибет. При желании он подключался к дополнительным игровым сценариям: выполнял задания, проходил сезонную прогрессию, участвовал в пикемах и открывал достижения.

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

Изначально PASS ориентировался прежде всего на поклонников киберспорта. Перед продуктом стояли сразу несколько задач: создать необычное для рынка решение, повысить долгосрочное удержание, мотивировать аудиторию возвращаться и при этом сохранить экономическую эффективность для бизнеса. Годовое сотрудничество с BLAST требовало не разовой промокампании, а инструмента, который мог бы развиваться вместе с турнирами, регулярно обновляться и поддерживать интерес аудитории.

За четыре года PASS заметно расширился. Из проекта для одной аудитории он превратился в систему, объединяющую игровые механики для различных видов спорта и пользовательских сегментов. Подробнее о том, как развивалась геймификация для бизнеса внутри PARI, можно рассказать через три ключевых направления: обновление технологического стека, развитие аналитики и создание универсальных механик.

Почему старый стек перестал справляться

Первоначальная версия PASS была разработана на PHP и устаревшей версии React. Пока продукт оставался относительно компактным, такой подход позволял быстро запускать новые функции. Но по мере роста аудитории и количества сценариев ограничения монолита становились всё заметнее.

Новый сервис или отдельную фичу было трудно подключить к уже существующим компонентам. Изменения затрагивали сразу несколько частей системы, релизы требовали больше времени, увеличивалась нагрузка на тестирование, а вероятность побочных ошибок росла. В результате запуск новой механики мог растянуться на месяцы, хотя сама идея требовала гораздо меньше времени.

Постепенно команда начала переводить проект на современную технологическую базу. Сейчас клиентская часть представляет собой React SPA с Tailwind CSS и TanStack Query. Серверная часть построена по принципам микросервисной архитектуры: основные сервисы написаны на Go, отдельные компоненты - на Node.js. Для взаимодействия используется REST, данные хранятся в PostgreSQL, кеширование организовано через Redis, а RabbitMQ отвечает за очереди сообщений.

Микросервисный подход не является универсальным решением без недостатков. Он усложняет синхронизацию команд, требует более чёткого распределения ответственности и заставляет поддерживать единое понимание продукта между несколькими разработчиками. Растёт и управленческая нагрузка: необходимо следить за контрактами между сервисами, совместимостью изменений и общей целостностью системы.

Однако для PASS преимущества оказались важнее сложностей. Разделение на независимые компоненты позволило командам работать параллельно, выпускать изменения точечно и не затрагивать весь продукт при каждом обновлении. Именно поэтому разработка игровой платформы перестала быть последовательной цепочкой из долгих согласований и превратилась в набор более управляемых задач.

Аналитика каждого шага пользователя

Одним из главных изменений стала работа с данными. Раньше команда в основном оценивала итоговые показатели: сколько пользователей активировали механику, сколько наград получили и какой оказался общий результат кампании. Такой подход не показывал, где именно пользователь терял интерес.

После внедрения детальной аналитики стало возможно отслеживать путь человека практически по шагам: увидел ли он баннер, открыл ли раздел, начал ли выполнение задания, сколько времени провёл внутри сценария, завершил ли активность и воспользовался ли наградой. Это помогает отличать проблему самой механики от неудачного интерфейса, недостаточно понятного описания или слишком сложного условия.

Такие данные полезны не только аналитикам. Продуктовая команда получает основу для быстрых итераций, маркетинг - понимание реакции аудитории, а бизнес - более точную оценку эффективности. Внедрение геймификации в этом случае перестаёт быть разовой креативной инициативой и становится управляемым процессом с измеримыми результатами.

Универсальные механики вместо одноразовых спецпроектов

Следующим шагом стало переиспользование компонентов. Если раньше игровая активность создавалась под конкретный турнир или рекламную кампанию, то теперь команда старается проектировать её как универсальный модуль. Сезонная прогрессия, задания, рейтинги, достижения и пикемы могут адаптироваться под разные события, виды спорта и сегменты аудитории.

Это меняет сам принцип работы. Вместо создания новой механики с нуля специалисты настраивают уже существующий сценарий: меняют правила, сроки, награды, визуальное оформление и условия участия. При этом базовая логика остаётся проверенной, а время запуска сокращается.

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

Что получилось в результате

В 2022 году PASS получил заметное внимание рынка: о проекте писали медиа, конкуренты предпринимали попытки создать похожие решения, а в 2023 году продукт получил серебряную награду премии Silver Mercury. Но главным результатом стал не только публичный успех, а переход от громкого спецпроекта к постоянно развиваемой платформе.

За 2025 год продуктом воспользовались около 600 тысяч уникальных пользователей. При этом команда получила возможность выпускать новые игровые сценарии значительно быстрее: вместо периода от нескольких месяцев до года отдельные механики теперь можно подготовить примерно за неделю - в зависимости от сложности и количества интеграций.

Подробное описание архитектурных решений и эволюции продукта представлено в материале о микросервисной архитектуре и игровых механиках PARI. Главное изменение состояло не в замене одного языка программирования другим, а в пересмотре всей логики разработки: продукт разделили на самостоятельные элементы, научились измерять каждый этап пользовательского пути и заложили повторное использование компонентов.

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

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

Прокрутить вверх