Ускорение продуктовой разработки без риска: строим API-шлюз для критичного ядра

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

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

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

Результат: зависимость от Java исчезла, запуск цифровых сервисов ускорился, а само ядро осталось нетронутым и стабильным.

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

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

Сотрудники площадок и администраторы получили современные инструменты управления, которые раньше невозможно было реализовать без длительной Java-разработки. Партнёрские сервисы смогли подключаться к билетной системе через единый и понятный API, не вникая в устройство legacy-ядра.

По сути, проект убрал невидимый, но критичный барьер между бизнесом и его цифровым будущим.

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

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

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

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

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

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

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

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

Стек и архитектурные решения.

Proxy API: Java (для нативной интеграции с legacy).

Внешний интерфейс: gRPC (обеспечил языковую нейтральность и высокую скорость обмена).

Хранение промежуточных данных: внешнее быстрое хранилище (снизило нагрузку на ядро и ускорило повторные запросы).

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

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

Процесс и взаимодействие. Работа шла в тесной связке с командой заказчика, которая отвечала за эксплуатацию ядра. С их стороны мы получали контекст и бизнес-правила, с нашей — восстанавливали техническую картину и предлагали архитектурные варианты. Пришлось отказаться от типовых «коробочных» интеграционных решений — они не учитывали специфику legacy-монолита и объёмов данных. Вместо этого родился собственный подход, который теперь можно масштабировать на другие проекты с похожими задачами.

Ключевой инсайт. Legacy-система — это не всегда проблема, которую нужно решать переписыванием. Часто это просто ядро, лишённое современного интерфейса. Если аккуратно «обернуть» его в правильный слой, оно продолжит надёжно работать, а бизнес получит свободу технологического манёвра. Самое сложное в таком подходе — не написание кода, а восстановление утраченных знаний о том, как система устроена внутри.

Скриншоты