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

В развитии IT-продуктов есть один типичный момент.

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

Мы столкнулись с этим в проекте с билетным ядром.

Компания много лет работала на стабильной системе на Java. Через неё проходило всё: события, залы, места, бронирования, статусы — фактически вся логика продаж. Система была надёжной и проверенной временем, и именно поэтому её нельзя было трогать.

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

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

Это означало, что любой новый продукт либо нужно писать на Java, либо искать обходные пути. Разработка дорожала, сроки росли, а часть идей становилась невыгодной ещё до старта.

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

Именно в этот момент стало понятно, что проблема не в отдельных сервисах.

Где на самом деле была проблема

На первый взгляд кажется, что дело в технологии. В Java, в старом коде, в легаси.

Но довольно быстро стало понятно: дело не в этом.

Проблема была в том, что у системы не было нормальной точки входа. Она не была рассчитана на внешние интеграции. Работать с ней можно было только «изнутри» и строго по её правилам.

То есть ограничение было архитектурным.

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

Нужно было решение, которое позволит развивать продукты, не трогая основу.

Когда решение — не переписывать

Мы отказались от идеи переписывания почти сразу.

Вместо этого решили изменить не систему, а способ взаимодействия с ней.

Так появился Proxy API — отдельный слой, который стал точкой входа в билетное ядро. Внутри он работает на Java и учитывает все ограничения legacy-системы, а наружу отдаёт уже современный gRPC API.

По сути, мы разделили старый и новый мир.

Ядро осталось как есть. Всё развитие вынесли наружу.

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

Когда начинаются реальные сложности

На практике всё оказалось сложнее, чем выглядело на старте.

У системы почти не было документации. Чтобы понять, как она работает, пришлось разбирать код и реальные сценарии. Мы по сути заново собирали архитектуру, чтобы не нарушить существующую логику.

Параллельно выяснилось, что объёмы данных значительно выше, чем ожидалось.

В отдельных сценариях один запрос мог обрабатывать сотни тысяч сущностей и доходить до 200–300 МБ. И это была нормальная рабочая нагрузка.

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

Поэтому Proxy API изначально проектировали как highload-решение. Данные обрабатывались поэтапно, лишние операции убирались, а промежуточные результаты выносились во внешнее быстрое хранилище.

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

Когда система перестаёт быть ограничением

После внедрения Proxy API ситуация изменилась довольно быстро.

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

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

При этом сама core-система осталась неизменной и продолжила работать так же стабильно, как и раньше.

Результат

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

В результате бизнес получил возможность развивать продукты быстрее и дешевле, без риска для стабильности core-системы.

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

📌 Полный кейс с архитектурой и деталями решения: https://itfox-web.ru/ru/cases/razrabotali-proxy-api-dlia-biletnogo-iadra-sniali-zavisimost-ot-java-i?utm_source=dzen&utm_medium=article&utm_campaign=case_proxy_api