Контекст и исходная проблема
Мы объединили игровой каталог, кошелёк и инструменты оператора в одной платформе. Основные задачи проекта — обслуживание игроков, точный учёт балансов и централизованное управление операциями.
Задачи и ограничения
При работе над проектом мы учитывали следующие задачи и ограничения.
- Одна пользовательская операция проходит через несколько систем. Успешный ответ игрового API ещё не означает, что финансовый учёт завершён корректно.
- Доступность каталога и корректность денег требуют разных критериев качества: временно скрытая игра и повторное списание не должны оцениваться как одинаковые сбои.
- Рабочие места сотрудников должны показывать историю событий и доступные действия, не раскрывая каждой роли все данные игрока.
Архитектура и взаимодействие модулей
Платформа разделена на пользовательский интерфейс, операционное ядро и внешние интеграции. PAM отвечает за аккаунты, кошелёк — за финансовые операции, адаптеры — за обмен с поставщиками. Бэк-офис обращается к этим контурам через контролируемые интерфейсы.
Регистрация, каталог, касса
PAM, кошелёк, бонусы
Игры и платежи
Бэк-офис → права доступа и операционные действия → ядро платформы. Ответы внешних API возвращаются в ядро и отражаются в интерфейсе игрока.
Критичная граница здесь — между событием внешней системы и изменением внутреннего баланса. В проекте мы отдельно описали идентификатор операции, допустимые переходы статусов и поведение при повторном уведомлении. Кэш может ускорять чтение, но сам по себе не гарантирует правильность финансового учёта.
Работы и этапы внедрения
В состав работ вошли аккаунты, кошелёк, бонусы, бэк-офис, игровые и платёжные подключения. Мы выполнили проектирование, разработку, нагрузочные проверки, оптимизацию серверной части и запуск.
Этапы работы над проектом
Работы разделены на последовательные этапы с проверкой ключевых сценариев.
Зафиксировать сценарии
Описать регистрацию, запуск игры, пополнение и вывод вместе с отказами, ожиданием и действиями поддержки.
Согласовать контракты
Определить владельцев данных и правила обмена: что передаётся в API, какие события повторяются и как искать расхождения.
Собрать сквозной контур
Связать интерфейс, платформенные модули и тестовые среды поставщиков; принимать не отдельные экраны, а завершённые операции.
Подготовить эксплуатацию
Согласовать наблюдаемость, инструкции поддержки и критерии, при которых выпуск приостанавливают.
Тестирование и подготовка к запуску
Проверки охватывают ключевые пользовательские и операционные сценарии проекта.
| Сценарий | Что проверяем |
|---|---|
| Повтор платежного уведомления | Одно внешнее событие не создаёт второе зачисление; история позволяет найти исходную операцию. |
| Тайм-аут игрового API | Игрок видит корректный статус, а оператор может определить, требуется ли повтор, ожидание или сверка. |
| Пиковая нагрузка | Проверяются задержки критичных сценариев и целостность операций, а не только число успешных HTTP-ответов. |
| Права сотрудника | Роль поддержки видит необходимые данные, но не получает несогласованные полномочия на изменение баланса. |
Для каждого сценария нужны исходные данные, ожидаемый результат и способ фиксации фактического поведения. Допустимую нагрузку, время восстановления и условия остановки запуска определяют вместе с оператором; универсальных значений для всех платформ здесь нет.
Результаты проекта
- Единая платформа
- Аккаунты, игры, платежи и бэк-офис работают в общей системе.
- Управление операциями
- Оператор получил инструменты управления игроками, промоакциями, правами и отчётностью.
Итоги проекта
Согласованная работа каталога, кошелька и бэк-офиса позволяет команде оператора управлять продуктом и отслеживать финансовые операции в едином контуре.