В финтехе технологии интеграций давно отработаны: стандарты есть, тесты автоматизированы, риски описаны. Однако сбои на стыках систем не прекращаются. Причины таких инцидентов часто не в коде или протоколах, а в размытой зоне ответственности за интеграции. О том, почему организационная прозрачность не менее важна, чем техническое совершенство, рассказывает Владислав Степанов, архитектор Nord Clan.
Технологии отлажены, а сбои остаются
Финтех-платформы сегодня связаны десятками интеграций: платежные шлюзы, антифрод-сервисы, скоринг, внешние базы данных. Интеграции встроены в процессы настолько глубоко, что воспринимаются как рутина. Технологии отлажены, подходы известны. В зрелых компаниях даже есть целые отделы, которые занимаются тестированием.
Несмотря на совершенство технологий, сбои на стыках систем продолжают фиксироваться регулярно. Анализ инцидентов показывает, что зачастую причина — не в незнании технических стандартов или недостатке компетенций, а в организационной плоскости. Интеграции находятся между командами: одна система отправляет данные, другая принимает. В результате за стык никто не отвечает целиком — у интеграций просто нет явного владельца.
Когда у интеграции нет общей цели и ответственного за результат, команды обычно оценивают ситуацию только в рамках своей системы. С технической точки зрения сервисы могут работать корректно, но бизнес при этом продолжает фиксировать ошибки транзакций или падение конверсии. Чтобы избежать таких ситуаций, за интеграцию должен отвечать явный владелец. Это обычно команда или архитектор, которые отвечают за ее работоспособность от постановки задачи до эксплуатации.
Для финтеха вопрос ответственного за интеграции приобретает особый смысл. Регуляторная ответственность требует четкого понимания, кто отвечает за каждый этап передачи данных. Если у интеграции нет владельца, комплаенс и аудит невозможны. Именно поэтому назначение ответственного становится необходимым условием для работы в регулируемой среде.
Код работает, а бизнес теряет деньги
Проблемы начинают проявляться еще на этапе постановки задачи. Типичный сценарий выглядит так: компания формулирует задачу в общем виде: «нужна интеграция с сервисом продажи билетов». Команда приступает к реализации без проработки концепции, целей и метрик.
Без цели невозможно спроектировать устойчивую интеграцию. Именно от нее зависят требования к производительности, сценарии отказоустойчивости и выбор типа взаимодействия между сервисами. Выход на новый рынок, дополнительная прибыль или удержание клиентов — каждая цель диктует свою архитектуру.
Когда происходит инцидент, возникает типичная ситуация: каждая команда проверяет свою часть работы и не находит ошибок. Разработчики говорят, что код работает. Смежные подразделения — что данные передаются корректно. При этом на уровне пользовательского сценария транзакция не проходит или падает конверсия. Проблема находится не внутри отдельного сервиса, а на границе между ними — там, где ответственность часто оказывается размыта. Инцидент удается локально исправить, но через некоторое время ситуация повторяется, потому что системная причина не устранена.
Чтобы исключить неоднозначность при сбоях, нужен иной подход к проектированию с самого начала. Интеграции нужно проектировать так же, как бизнес-продукт: с понятной целью, метриками и ответственными за результат. Например, в одном из проектов по развитию микросервисной платформы дистанционного банковского обслуживания интеграции строились сразу с десятками внутренних систем банка — АБС, CRM, антифрод-сервисами и платежными модулями. В таких условиях управление взаимодействиями между сервисами становится самостоятельной архитектурной задачей и требует четко выстроенных интеграционных контрактов и единых стандартов обмена данными.
Центр компетенций: расходы, которые экономят деньги
Когда интеграций становятся десятки, а команд-потребителей — сотни, возникает новый вызов: как стандартизировать подходы, если каждая команда действует по-своему?
Некоторые компании для этого выделяют интеграции в отдельное направление — центр компетенций. Кажется, что это дополнительная статья расходов. Однако на практике это снижает расходы и делает архитектуру более предсказуемой.
Центр компетенций задает стандарты: какие протоколы использовать, как управлять версиями контрактов, когда выбирать синхрон, а когда — асинхрон. Команды-потребители продолжают отвечать за свои интеграции, но делают это по единым правилам.
В результате исчезает множество разрозненных решений и появляется экосистема, где новые интеграции встраиваются в уже существующую архитектуру. Централизация экспертизы напрямую снижает стоимость разработки и эксплуатации: профессиональная команда один раз выстраивает стандарты, которым все следуют.
Один клиент — два имени: почему сервисы не понимают друг друга
Если команда разработки продукта и команда, отвечающая за внешние интеграции, говорят на разных языках и используют разные спецификации, последствия неизбежны. Расходятся контракты: nullable-поля интерпретируют по-разному, enum-значения не совпадают, форматы дат понимаются неодинаково. Возникают конфликты семантики: «клиент» в одном сервисе становится «пользователем» в другом. Разные подходы к управлению контрактами приводят к несовместимости.
По отдельности такие проблемы решаются парой строк кода. Однако в совокупности они способны парализовать всю работу системы.
Предотвратить это можно еще до начала разработки. Первый шаг — проектирование контрактов. API-first подход означает, что сервис стартует не с реализации, а с описания того, как он будет взаимодействовать с другими. Это заставляет команды заранее договориться о типах данных, форматах, обязательных и опциональных полях.
Каждое интеграционное решение фиксируется в ADR — архитектурной записке, где объясняется, почему выбран тот или иной подход. Это позволяет вернуться к логике выбора через месяцы или годы. Когда контракты готовы, интеграционное тестирование встраивается в CI/CD. Это гарантирует, что изменения в одной системе не сломают смежные.
Например, у Nord Clan была задача спроектировать взаимодействие сразу с несколькими государственными системами — ФНС, ЕСИА и ЕБС. Разные форматы данных и требования к передаче информации требовали заранее согласованных контрактов и строгой валидации на уровне интеграций.
Ошибка в проектировании, за которую платят в Черную пятницу
Неправильный выбор типа взаимодействия между сервисами — еще одно следствие отсутствия единого архитектурного центра. Например, сервис платежей делает синхронный вызов к сервису антифрода и блокирует поток, ожидая ответа. В обычный день антифрод отвечает за 50 миллисекунд. Однако в период высокой нагрузки, например, в «Черную пятницу», нагрузка вырастает в десять раз, а время ответа увеличивается до 2–5 секунд. Платежный шлюз исчерпывает пул соединений. В результате блокируются все платежи, включая те, которым проверка вообще не нужна.
Такие сбои часто выглядят как техническая ошибка, хотя на самом деле являются следствием архитектурного решения, принятого на этапе проектирования. В данном случае, на этапе проектирования никто не заложил асинхронную обработку.
Поэтому выбор между синхронными и асинхронными взаимодействиями должен приниматься заранее — исходя из ожидаемой нагрузки, сценариев отказа и бизнес-метрик.
Безопасность: то, о чем вспоминают после кражи данных
Стыки систем часто становятся одной из самых уязвимых точек финтех-архитектуры с точки зрения безопасности. Пока каждая команда отвечает за свой сервис, безопасность взаимодействия между ними может оставаться вне фокуса. Именно здесь возникают типичные бреши трех типов. Одни сервисы недостаточно проверяют входящие данные — и злоумышленник может подменить платежные реквизиты. Другие передают избыточную информацию, создавая риски утечки финансовых и персональных данных. Третьи не проверяют, кто к ним обращается, — и мошенник выдает себя за легитимный сервис.
Такие проблемы редко проявляются в ежедневной работе — каждый сервис по отдельности функционирует корректно, поэтому уязвимость на уровне взаимодействия остается незаметной. Обнаружить ее можно только при целенаправленном анализе всей цепочки интеграций.
Понять, где именно находится угроза, помогает аудит. Это не разовая проверка, а системный процесс. Аудит включает в себя: инвентаризацию всех интеграционных точек, классификацию по критичности, проверку контрактов на полноту и непротиворечивость, а также аудит безопасности и нагрузочное тестирование. В результате получается бэклог задач с приоритетами и реестр рисков с оценкой вероятности. Становится понятно, что нужно дорабатывать и в какой очередности.
Интеграционный ад: когда хаос становится неизбежным
Большинство быстрорастущих финтех-проектов рано или поздно сталкиваются с тем, что количество интеграций начинает превышать управляемость архитектуры. Многие проекты попадают в «интеграционный ад» именно потому, что в погоне за скоростью пренебрегают архитектурной дисциплиной.
Системный подход к архитектуре требует набора работающих практик, которые внедряются с первого дня. Проектирование контрактов до старта разработки, фиксация ключевых решений в ADR, автоматизированное тестирование стыков — все это страхует от ситуаций, когда интеграции становятся неуправляемыми и блокируют масштабирование.
Заключение
Технологические инструменты интеграций давно стали стандартом. Устойчивость системы определяют не столько протоколы и API, сколько согласованность архитектуры и четкие границы ответственности между командами. Интеграции здесь требуют особого внимания: как самостоятельная часть архитектуры, они нуждаются в системном управлении. Иначе одни и те же ошибки будут повторяться от проекта к проекту, а сбои на стыках систем будут продолжать приносить рынку миллионные потери.
