Архитектура конструктора Origination: запуск продукта за день вместо двух месяцев разработки

Привет, Хабр! Я Павел Гордеев, архитектор в Т-Банке в ИТ-хабе Самары. Моя статья — часть проекта «20 в 20» к 20-летию Т-Банка. В рамках этого проекта 20 инженеров из 20 городов рассказывают свои истории, чтобы показать, как выглядит наша распределенная ИТ-карта.

Самара — один из ИТ-хабов Т-Банка. Мы открылись в 2021 году и за пять лет выросли с нуля до 300 человек. Я работаю в кроссрегиональной команде T-Bank Origination Platform с ребятами из Самары, Москвы, Воронежа и Санкт-Петербурга. Мы делаем платформу, через которую проходит каждый клиент банка — от первой заявки на кредитную карту до подключения сложных продуктов для бизнеса.

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

Что такое TOP-платформа

TOP (T-Bank Origination Platform) — платформа, через которую проходит каждый клиент Т-Банка: от первой заявки на карту до подключения продуктов для бизнеса. При этом неважно, является ли клиент новым или уже пользуется экосистемой.

Масштаб платформы: миллионы заявок ежемесячно, доступность от 99,9%, время отклика менее 200мс на основных сценариях.

Ключевое направление — Конструктор Origination. Единый конфигурируемый ориджин для WEB и мобильного банка. Цель — сократить Time-to-Market с 2 месяцев разработки до 1—3 дней.

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

Технически это: 

• DSL для описания сценариев — декларативный язык, в котором продуктовик описывает шаги ориджина, поля, условия показа, интеграции с внешними системами. 

• Адаптер под существующие системы — конструктор умеет работать и со старыми сценариями, и с новыми, чтобы миграция была постепенной.

• BFF-слой — бэкенд для фронта, который собирает данные из разных сервисов (Filler, Storage, Status) и отдает фронту готовый view-model.

Сейчас мы в активной разработке: первая итерация запланирована на конец октября 2026, полный релиз — к концу года.

Почему старая архитектура не работала

Старая схема: клиент → 15 сервисов. Каждый экран формы требовал отдельного запроса к бэкенду.

Проблемы:

• Новый продукт запускался за 2 месяца разработки.

• Под каждый флоу нужна была отдельная команда фронтенда.

• Согласование дизайнов и тестирование занимали большую часть времени (до 50% от общего цикла).

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

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

Мы собрали требования к платформе:

• Доступность от 99,9%.

• Время отклика менее 200мс на основных сценариях.

• Масштабируемость под пиковые нагрузки (распродажи, маркетинговые акции).

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

Техническая реализация BFF-слоя

Backend for frontend — отдельный бэкенд-микросервис, который управляет отображением на UI. BFF нужен для быстрого и безрелизного обновления фронтенда.

Когда появляется задача безрелизного управления UI на разных устройствах, остается только смотреть, как правильно применить BFF-паттерн.

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

Основная проблема была в том, что под каждый флоу сбора данных заявок конкретного продукта приходилось тратить много времени:

• на ожидание команды фронт-разработки, которая сможет заняться этим;

• согласование дизайнов каждого флоу;

• разработку и тестирование.

Стандартно весь процесс занимал месяц. В банке часто запускаются новые продукты, и платформа становилась узким местом разработки.

Нужно было придумать движок, который позволит только настроить в платформе «я хочу для процесса заявки собрать с клиента поля 1, 2, 3 и вперед», и дальше платформа самостоятельно собирала UI-флоу для клиента. Так родилась система, где фронт только исполняет команды и рендерит те блоки, которые сообщит ему бэк. DSL каждого экрана и форм присылает бэк. Это дает необходимую гибкость и скорость создания новых флоу.

Фронт должен на каждый новый экран делать запрос на бэк (с медленным интернетом могут быть проблемы). Для MVP посчитали это приемлемым решением. Заложили на будущее возможность заранее прогружать несколько экранов с бэка.

Сложности реализации. Основная сложность не в коде, а в согласовании, какие данные куда будут отгружаться. Особенно для мультипродуктовых сценариев, где заявка оформляется сразу на несколько продуктов с пересекающимися наборами атрибутов. Потребовалось договориться о зонах ответственности за разные части процесса, настроить правильную передачу контекста между сервисами, обеспечить backward compatibility при изменении контрактов.

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

Основной стек: 

• Java — основной язык бэкенда (Spring Boot, микросервисы). 

• React — фронтенд-фреймворк для WEB. 

• Kafka — асинхронная интеграция между сервисами. 

• PostgreSQL — основная база данных.

• Kubernetes — оркестрация контейнеров. 

• GitLab CI/CD — пайплайны, деплои.

Инфраструктура: 

• Микросервисная архитектура — REST API.

• Мониторинг и алертинг (Grafana, Prometheus). 

• Логирование (Sage, ELK).

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

Команда и культура 

Самарский ИТ-хаб входит в состав группы «Т-Технологии» — технологического ядра Т-Банка. Мы взаимодействуем с другими хабами по всей стране: Нижним Новгородом, Санкт-Петербургом, Екатеринбургом, Казанью, Минском.

В Самаре три ключевые роли:

• Java-разработчики — бэкенд-сервисы, микросервисы, высоконагруженные системы;

• QA-инженеры — тестирование, автоматизация, качество;

• Системные аналитики — проектирование интеграций, контрактов, API.

Такая структура позволяет закрывать полный цикл разработки: от анализа требований до релиза и поддержки. Из платформы TOP у нас работает 13 инженеров — большая часть команды.

Раз в 1—3 месяца проводим внутренние митапы для Java-разработчиков. Формат: один-два доклада по 40 минут и Q&A. Темы — от разбора новых фич Java до кейсов оптимизации высоконагруженных сервисов. Митапы открыты для всех желающих из других хабов — подключаемся онлайн. Записи выкладываем во внутреннюю базу знаний. После митапов всегда много кулуарного общения и идей, как лучше что-то реализовать.

Еще у нас есть ежегодное мероприятие для студентов, которое объединяет программирование и спорт, — Код спорта. Команды до трех человек чередуют решение задач по программированию и спортивные задания: нужно быть быстрым и в коде, и на дистанции. Мероприятие проводим вместе с другими хабами, участники подключаются из разных городов. В 2026 году пришел 51 человек. Для нас это способ познакомиться с будущими стажерами и показать, что работа в Т-Банке — не только код, но и активное комьюнити. Главный приз — Lego-банкоматы, которые собираются в фигурку фирменного банкомата Т-Банка. Участники уносили не только эмоции, но и конструктор.

Каждое лето команда участвует в «Гонке Героев» — экстремальном забеге с препятствиями. Дистанция — около 10 км, более 30 препятствий: рвы с водой, стены, канаты, грязь. Участвуем командой из 10 человек, действует правило взаимовыручки: сильные подсаживают тех, кто пониже, и вытягивают тех, кто устал. Это тимбилдинг, после которого рабочие вопросы решаются проще.

Зимой мы организуем выезды на Красную Глинку в Самаре и в другие города. Катаемся все: от джунов до тимлидов. По пятницам после обеда играем в настолки. Несколько раз в год проводим внутренние турниры по настольному теннису. А для тех, кто предпочитает стратегию, устраиваем шахматные турниры. Играем по швейцарской системе, несколько туров за обедом. Участвуют все уровни — от новичков до кандидатов в мастера.

Каждую неделю по утрам в офисе проходят занятия с тренером. 45 минут, коврики предоставляет компания, уровень — любой. Начинать день с растяжки вместо утреннего дашборда — отличный ритуал, который прижился в хабе. Самара — хаб с энергией стартапа, но с ресурсами большой компании. Мы строим платформу, которой пользуются миллионы клиентов. И это только начало.

Выводы

Идея такого легкого для запуска конструктора витала в платформе несколько лет. Но очень долго не решались подходить к такому снаряду, потому что приходилось учитывать интересы очень многих сторон.

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

И тут самое сложное — попытаться предугадать, как же домен может развиваться, чтобы продумать forward compatibility и меньше делать миграций в будущем. 

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

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