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

Главное о кейсе

Крупная компания с сетью культурных и спортивных площадок уперлась в архитектурный тупик: стабильное билетное ядро на Java могло работать только с Java-приложениями. Любой новый цифровой продукт (мобильное приложение, веб-сервис, партнерская интеграция) требовал либо переписывания ядра, либо невозможного прямого подключения. Мы разработали изолированный Proxy API на gRPC — высоконагруженный промежуточный слой, который связал legacy-ядро с любым современным стеком. Вместо рискованной и дорогой переработки core-системы заказчик получил универсальную точку входа, снял критическую зависимость от Java-разработки и заложил основу для безопасного параллельного масштабирования продуктовой экосистемы.

Как проект изменил жизнь пользователей

Для конечных пользователей проект означал не «новый интерфейс», а исчезновение барьера между ними и сервисом. Раньше запуск новой функции (онлайн-покупки билетов, интеграции с партнерскими платформами, мобильного приложения) упирался в техническую невозможность подключить современный интерфейс к старому ядру. Теперь пользователи получают быстрый доступ к билетам и услугам через удобные современные приложения, а не через устаревшие или ограниченные интерфейсы. Бизнес перестал быть заложником одного технологического стека, и это напрямую влияет на скорость появления новых сервисов для посетителей музеев, театров и спортивных объектов.

Бизнес-задача и ее решение

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

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

Решение: мы разработали изолированный Proxy API на gRPC — промежуточный высоконагруженный слой, который связал legacy-ядро с новыми продуктами без вмешательства во внутреннюю логику core-системы.

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

Крафт (мастерство), реализация, технические детали

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

Что именно сделали:

Спроектировали контракт взаимодействия (gRPC-сервисы) так, чтобы он был полностью независим от внутренней логики ядра и мог развиваться отдельно.

Обеспечили высокую нагрузку: Proxy API спроектирован как слой, способный выдерживать пиковые обращения к билетной системе без деградации.

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

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

Это не «обертка» и не «костыль» — это архитектурный слой, который превращает закрытую систему в управляемую платформу.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

Стартовая ситуация. У заказчика было стабильное, проверенное временем билетное ядро на Java, от которого зависела работа всех точек продаж. Но вокруг него начали появляться новые продукты, и выяснилось: ядро «не видит» ничего, кроме Java. Прямое подключение современных фронтендов и сторонних интеграций было невозможно, а документации для внешних разработчиков не существовало.

Развилка. Классический путь — переписать или заменить ядро — означал бы остановку или серьезный риск для действующего бизнеса. Это было неприемлемо.

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

Проверка и реализация. Мы спроектировали Proxy API на gRPC как самостоятельный высоконагруженный сервис. Ядро осталось «черным ящиком», но теперь у бизнеса появилась универсальная точка входа. Процесс с заказчиком строился вокруг одного принципа: сначала доказываем, что ядро можно безопасно «обойти» снаружи, потом строим продукт.

Инсайт. Legacy-систему не всегда нужно убивать. Иногда достаточно построить вокруг нее правильный архитектурный слой — и она перестает быть тормозом.

Скриншоты