Никита Летов, архитектор финтех-систем, Java Tech Lead, IEEE Senior Member и Hackathon Raptors Fellow поделился своими подходами к созданию надежной авторизации и рассказал, какие технологические принципы формируют архитектуру современных банковских и платежных сервисов. 5 апреля пользователи по всей России столкнулись со сбоями в работе системы быстрых платежей (СБП), а также в работе приложений Альфа-Банка и T-Банка.

Для крупных банковских приложений бесперебойная работа критически важна, так как любые простои и сбои напрямую связаны с рисками финансовых потерь. Именно в такие моменты становятся очевидны наиболее уязвимые узлы, один из которых авторизация — точка входа пользователей в приложение, говорит Никита Летов, software engineer и эксперт по построению отказоустойчивых систем. В качестве технического лидера и руководителя Java-разработки в Росбанке он координировал работу нескольких команд, отвечал за архитектуру мобильного банкинга и ключевые элементы системы — от авторизации до доступности сервиса. Ему удалось значительно повысить стабильность приложения и в десятки раз сократить жалобы пользователей на трудности с авторизацией. Никита состоит в международных объединениях инженеров-разработчиков IEEE и Hackathon Raptors, которые предъявляют высокие требования к своим кандидатам — их уровень должен соответствовать мировым стандартам. В интервью эксперт рассказал, какие архитектурные решения позволяют избежать большинства типичных проблем с авторизацией и выдерживать нагрузку без сбоев, чем отличается разработка в финтехе от других отраслей и какие технические направления будут на пике востребованности в ближайшие несколько лет.

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

Требования к финтех-решениям действительно стали максимально высокими, и IT-команды сталкиваются с целым рядом серьезных вызовов. Один из самых важных — обеспечение высокой доступности сервиса. Банковские приложения должны работать 24/7 и выдерживать тысячи, а порой и миллионы одновременных пользовательских сессий. При этом приоритетом остается безопасность. Финансовые данные всегда представляют интерес для злоумышленников, любая уязвимость может обернуться серьезными финансовыми и репутационными последствиями. Еще одна важная особенность — финтех-продукты не живут в изоляции. Почти всегда они связаны с множеством внешних систем: от госучреждений до страховых компаний и партнерских платформ. Эти интеграции нужно не просто настроить, а выстроить так, чтобы обеспечивалась надежная транзитивность данных и устойчивость при обновлениях. Отдельный вызов — масштабируемость. Базапользователей постоянно растет: каждый день, а иногда каждую минуту, приходят новые клиенты или возвращаются старые, и решения, которые отлично справлялись с нагрузкой вчера, завтра могут эту нагрузку не выдержать. Поэтому архитектуру нужно изначально проектировать с учетом роста: гибкую, расширяемую, на основе глубокого знания системного дизайна. И, конечно, нельзя забывать о соответствии регуляторным требованиям. Это, пожалуй, одна из самых сложных и наименее любимых задач. Банки, брокеры и других финтех организации работают под пристальным надзором государственных регуляторов, поэтому приходится учитывать множество законодательных норм. Очень часто это сильно сужает выбор технологий, которые можно применять для решения той или иной задачи.

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

Когда у системы миллионная база пользователей, авторизация перестает быть просто проверкой логина и пароля — она превращается в полноценный высоконагруженный сервис, к которому предъявляются те же требования, что и к другим критическим компонентам системы: он должен быть быстрым, надежным и безопасным. Первое, что меняется — это масштаб и хранение сессий. Классические подходы, вроде хранения сессий пользователей в памяти, уже не подходят: они не масштабируются горизонтально. Поэтому авторизация должна быть stateless, а все запросы должны аутентифицироваться по токенам, например, по JWT. При этом авторизация разделяется на два режима: полная — с проверкой пароля и 2FA, и быстрая — когда пользователь заходит по ранее выданному токену. В обоих случаях критично обеспечить безопасный обмен токенами, чтобы злоумышленник не мог его перехватить. Еще один важный момент — неравномерность нагрузки. Например, утром в понедельник или в последнее число месяца, когда приходит зарплата, нагрузка на вход в мобильное приложение может быть аномально высокой по сравнению с обычным трафиком. Такие пики необходимо уметь обрабатывать, не допуская веерного отказа сервиса. Здесь помогают решения вроде Circuit Breaker, чтобы изолировать сбойные компоненты, или динамический апскейлинг, который позволяет оперативно увеличивать число копий сервисов в зависимости от нагрузок. Ну и, конечно, не обойтись без fallback-механизмов. Сбои возможны даже при идеально спроектированной системе — и важно, чтобы они обрабатывались прозрачно для пользователя: либо за счет резервной логики, либо, если совсем критично, с предложением альтернативных шагов, чтобы пользователь все равно мог завершить задачу.

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

Это был один из тех случаев, когда, казалось бы, всё работает, но на деле клиенты сталкивались с ошибками каждый день. Для меня это был как раз тот случай, когда нужно было «копать вглубь» и не принимать архитектуру как нечто данное. Проблемы проявлялись на стороне пользователей: кто-то не мог войти после обновления приложения, у кого-то авторизация занимала до 15 секунд, а у части клиентов вообще ничего не происходило — просто белый экран. В техподдержку такие обращения поступали постоянно, и они составляли до трети всех тикетов. Первым делом я занялся трассировкой клиентских запросов. Мы внедрили распределённый трейсинг и усовершенствовали систему логирования на всех ключевых этапах прохождения авторизации — от gateway до ответственных backend сервисов. Это позволило точно определить, где именно «рвётся цепочка». В итоге выяснилось, что в процессе авторизации возникало множество проблем. Одна из них была связана с не консистентной маршрутизацией — gateway направлял клиентов на не соответствующие версии сервисов. Другая — с утечкой контекста безопасности во время авторизации. Кроме того, возникали проблемы с сетевой доступностью кеша, в которой временно хранилась метаинформация о токенах. Большинство проблем удалось решить за счет переписывания кода gateway и фильтров сервиса авторизации. А сбой с доступом к кешу оказался вызван банальной причиной — отсутствием сетевых правил в оркестраторе backend-сервисов. Этот кейс показал мне, насколько важно разрабатывать критические участки системы не просто как отдельную фичу, а как полноценную инженерную платформу, где продумано всё — от UX до SLA.

В период вашей работы в банке его приложение стало работать заметно стабильнее — доступность выросла до 99,97%. Какую технологию вы применили, как удалось добиться такой высокой стабильности работы?

После того как я столкнулся с не консистентной маршрутизацией и начал выстраивать прозрачность запросов, я решил внедрить Spring Cloud Gateway. Но важно понимать, что стабильность и высокая доступность приложения не достигаются за счёт одной технологии, не существует так называемой «серебряной пули», которая решает все проблемы разом. Spring Cloud Gateway, не дал мгновенного или «волшебного» прироста доступности, но сыграл роль в достижении этого показателя. Результата удалось достичь за счёт слаженной и системной работы всех команд разработки. С самого начала, работая в роли технического лидера, я выстраивал процессы так, чтобы минимизировать вероятность ошибок и скрытых дефектов. А в случае их возникновения — обеспечить максимально быструю реакцию. Именно тогда мы приняли решение выращивать собственных SRE-инженеров внутри команды — и успешно реализовали это направление. В итоге, сочетание факторов: распространение event-driven архитектуры во всей backend-части платформы дистанционного банковского обслуживания, сильное техническое лидерство, зрелые процессы разработки и тестирования, а также грамотный выбор технологий — позволили нам выйти на очень высокие показатели доступности для высоконагруженного банковского приложения.

Никита, вы активно общаетесь с профессиональным сообществом: выступаете на профильных конференциях, состоите в ассоциациях IEEE и Hackathon Raptors, куда принимают только высококлассных специалистов, уже зарекомендовавших себя. Есть ли среди текущих трендов в разработке финтеха те, которые вы бы назвали переоценными, а что, наоборот, пока тихо развивается, но скоро «выстрелит»?

Да, это интересный вопрос. На мой взгляд, в данный момент очень сильно переоценено направление внедрения LLM-моделей в приложения без чёткого понимания целей и ограничений. Причём это справедливо не только для финтех-индустрии, но и для всего ИТ в целом. Чаще всего это выглядит так: «Давайте добавим ИИ, потому что это модно», — но при этом не решается реальная бизнес-проблема. Да, технология мощная, но она должна применяться осознанно, с учётом регуляторных требований, интерпретируемости и безопасности. В результате такого необдуманного использования AI мы чаще всего видим красивые демоверсии и MVP, но крайне мало реальной пользы на проде. А вот что, на мой взгляд, недооценено и точно «выстрелит» в ближайшее время, а местами уже выстрелило — это распространение event-driven архитектур и асинхронной обработки событий. Особенно в банках, где раньше всё строилось на синхронных REST-запросах. Сейчас, когда нагрузка растёт, и миллионы операций проходят параллельно, переход на реактивные подходы и использование таких брокеров сообщений, как Apache Kafka или Pulsar, становится не просто «плюсом», а по сути — необходимостью. Уже сейчас заметен тренд: во многих проектах event sourcing позволяет делать откаты к любой точке восстановления, обеспечивать гибкий аудит и собирать аналитику, близкую к реальному времени, без удушающих нагрузок на базы данных. Кроме того, при таком подходе нет привязки к конкретной базе данных — можно в любой момент настроить потребление событий из брокера в любую подходящую базу, изменив при этом и структуру данных. Ещё один «тихий» тренд, не столько относящийся к разработке, сколько к инфраструктуре, — это растущая популярность serverless-подходов внутри корпораций. Раньше это казалось уделом стартапов, но теперь даже крупные финтех-компании начинают активно использовать FaaS и lightweight-контейнеры для решения задач: от AML-сценариев до генерации отчётов. Всё это ускоряет time-to-market и даёт гибкость — особенно в условиях ограниченных бюджетов и небольших команд. Так что шум — не всегда показатель зрелости, и наоборот, — самые полезные вещи часто приходят тихо, но надолго.