Избавились от зависимости от Java и ускорили запуск новых сервисов.

Заказчик - Крупная компания с распределённой сетью культурных и спортивных площадок.

Задача - ускорить запуск новых цифровых продуктов (мобильных приложений и веб-сервисов), не прибегая к дорогостоящей и рискованной переработке своего ключевого элемента инфраструктуры — стабильного, но технологически закрытого билетного ядра на Java. 

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

В качестве решения команда АЙТИФОКС разработала изолированный Proxy API на gRPC — промежуточный высоконагруженный слой, который связал legacy-ядро на Java с новыми цифровыми продуктами без вмешательства во внутреннюю логику core-системы.

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

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

Это была стабильная и проверенная временем legacy-система на Java, от которой напрямую зависела работа всех точек продаж и онлайн-сервисов.

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

Из-за этого разработка новых сервисов упиралась в ограничения стека и высокую стоимость Java-разработки. Запуск новых продуктов замедлялся, а часть инициатив становилась экономически нецелесообразной ещё на этапе планирования.

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

В этом кейсе рассказываем, как АЙТИФОКС решил задачу интеграции с legacy-системой и разработал Proxy API на gRPC — промежуточный слой, который связал билетное ядро на Java с современными мобильными приложениями, веб-сервисами и внешними системами.

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

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

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

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

Команда АЙТИФОКС спроектировала отдельный интеграционный слой — Proxy API, не вмешиваясь в работу legacy-ядра.

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

По сути, мы сделали универсальный интеграционный слой между legacy-системой и современной продуктовой экосистемой.

Proxy API стал единой точкой входа к билетному ядру и сразу решил несколько ключевых задач:

• развитие новых продуктов перестало зависеть от одного стека (Java);
• сохранилась стабильность core-системы без вмешательства в её логику;
• появилась единая и управляемая точка интеграции для всех сервисов и внешних систем.

В такие legacy-системы обычно не вмешиваются. Если решение на Java стабильно работает годами, его продолжают развивать в рамках того же стека — переписывание слишком рискованно и дорого, особенно когда речь идёт о системе, на которой держится бизнес.

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

Сложности при этом были существенные: документации не было, объёмы данных — большие, цена ошибки — высокая. Чтобы реализовать решение, нам пришлось глубоко разбираться в архитектуре legacy-системы и фактически восстанавливать логику её работы.

Мы сознательно отказались от типовых решений «из коробки». Вместо этого спроектировали и внедрили собственный подход к интеграции, встроив новый слой в существующую архитектуру так, чтобы он стал частью инфраструктуры, а не временным обходным решением.

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

Обрабатывать такие объёмы напрямую было нельзя — это приводило бы к задержкам, перегрузке системы и нестабильной работе продуктов. Поэтому Proxy API изначально проектировался как highload-решение с учётом реальных сценариев нагрузки.

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

Прокси-сервер работал как изолированный слой и не создавал дополнительного давления на core-систему даже при пиковых нагрузках. Мы сразу заложили архитектуру под большие объёмы данных — и благодаря этому не столкнулись с проблемами уже в продакшене.

Что получил бизнес:

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

Что получили мы:

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

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

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

Много лет компания работала на стабильном билетном ядре на Java, но развитие новых продуктов упиралось в технологические ограничения. Мы не стали переписывать ядро, а сделали Proxy API — промежуточный слой, который связал легаси-систему с мобильными, веб- и внешними продуктами. В результате команда получила возможность развивать экосистему дальше без риска для core-системы и зависимости от одного стека.