Разработка Proxy API для интеграции билетного ядра с мобильными и веб-продуктами

1. Вводная задача от заказчика, проблематика, цели

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

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

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

Это замедляло развитие. Любой новый продукт требовал Java-разработки, что увеличивало стоимость и сроки запуска. Переписывать ядро было нельзя — это многолетняя система с высокой ценой ошибки. Любые сбои напрямую влияли бы на продажи и работу сервисов.

Задача проекта — открыть билетное ядро для новых продуктов, сохранить его стабильность и снять зависимость от одного технологического стека.

2. Описание реализации кейса и творческого пути по поиску оптимального решения

На старте стало понятно: проблема не в конкретных продуктах, а в самой точке входа к ядру. Система была закрытой и могла взаимодействовать только с Java-клиентами по внутренним правилам.

Переписывать ядро — дорого и рискованно. Поэтому мы приняли архитектурное решение: не менять основную систему, а построить вокруг неё отдельный интеграционный слой.

Так появился Proxy API. Сервер был написан на Java, чтобы корректно взаимодействовать с билетным ядром. Наружу он предоставлял gRPC API — быстрый и строгий протокол взаимодействия, который позволяет работать с системой сервисам на любом языке разработки.

Proxy API стал единственной точкой входа к ядру и изолировал его от внешних систем. Это позволило сохранить существующую бизнес-логику и одновременно открыть её для современной продуктовой экосистемы.

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

Отдельный вызов — объёмы данных. В некоторых сценариях один запрос включал сотни тысяч сущностей и до 200–300 МБ информации. Поэтому Proxy API проектировался сразу с учётом высокой нагрузки: данные обрабатывались поэтапно, а промежуточные результаты сохранялись во внешнем быстром хранилище. Это снизило нагрузку на основную систему и обеспечило стабильную работу даже при пиковых обращениях.

3. Результаты сотрудничества

После внедрения Proxy API развитие новых продуктов перестало зависеть от Java-стека.

Команда получила:

• — возможность запускать мобильные и веб-продукты на подходящих технологиях;
• — безопасную интеграцию с внешними платформами без прямого доступа к ядру;
• — единую контролируемую точку входа ко всей бизнес-логике;
• — возможность развивать несколько продуктовых направлений параллельно.

Стабильность билетного ядра при этом полностью сохранилась. Новые сервисы больше не создают прямую нагрузку на основную систему и не требуют вмешательства в её код.

Компания получила архитектурную основу для дальнейшего роста: запуск новых продуктов перестал зависеть от технологических ограничений устаревшей системы.

4. Заключение

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

Мы не стали переписывать устаревшее ядро и не пошли по пути дорогостоящей миграции. Вместо этого аккуратно встроили интеграционный слой, который открыл систему для новых продуктов и современных технологий.

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

Станислав Позарков

Менеджер проекта, АЙТИФОКС

Проект был технически очень интересным. Мы сделали глубокую интеграцию с билетным ядром и реализовали архитектуру на базе gRPC и микросервисов. Это позволило гибко настраивать систему и обеспечить высокую скорость внутреннего обмена данными. Даже аудиторы обращали внимание на выбранную архитектуру — решения получились нетипичными, но они действительно закрывали реальные задачи системы.