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

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

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

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

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

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

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

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

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

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

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