Я не добавляю сервис в архитектуру, пока не знаю, что будет без него

Я не добавляю новый сервис в архитектуру, пока не понимаю, что произойдёт в рабочий день, если он замолчит. Не «когда-нибудь случится авария», а очень конкретно: сможет ли клиент оформить заказ, увидит ли сотрудник данные, сколько задач зависнет и кто первым заметит проблему.

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

Зависимость — это обещание

Когда одна часть системы обращается к другой, она делает обещание пользователю. Например: «после оплаты заказ появится в кабинете», «после загрузки файла документ будет доступен», «после отправки формы менеджер получит уведомление». Если в середине этого обещания стоит внешний сервис, он становится частью результата, который ждёт человек.

Поэтому вопрос не сводится к API и документации. Он про границу ответственности. Я хочу знать владельца связи, условия работы, понятный сигнал о сбое и безопасное поведение системы, пока связь не восстановлена. Этот подход близок к тому, почему у интеграции должен быть владелец ошибки.

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

Сначала один маршрут пользователя

Вместо схемы из десятков прямоугольников я бы взял один маршрут. Допустим, клиент оставляет заявку. Сайт сохраняет её, CRM создаёт карточку, сервис сообщений отправляет уведомление, а менеджер берёт заявку в работу. Затем я задаю простой вопрос на каждой точке: что произойдёт, если она недоступна пять минут, час, сутки?

Ответы редко одинаковы. Если уведомление придёт с задержкой, заявка может спокойно ждать в очереди. Если не сохранилась сама заявка, это уже другой риск. Если CRM недоступна, возможно, нужен временный журнал и понятный порядок последующего переноса. Архитектура становится полезной именно в таких различиях, а не в красоте схемы.

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

Четыре решения, которые стоит принять заранее

1. Что остаётся доступным. Базовое действие пользователя не должно исчезнуть только потому, что второстепенный сервис не ответил.
2. Что откладывается. Некоторые операции можно честно поставить в очередь и выполнить позже, не создавая двойных записей.
3. Что видит человек. Лучше спокойное «заявка принята, статус обновится позже», чем молчание или техническая ошибка.
4. Кто разбирает сбой. Должны быть владелец, сигнал и путь эскалации, а не общий чат с вопросом «у кого-нибудь работает?».

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

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

Опасность «быстрых» связей

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

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

Архитектурный выбор должен быть обратимым

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

Обратимость не значит, что надо бояться нового. Она значит, что эксперимент не должен превращать бизнес в заложника одной непроверенной точки.

Практическая проверка

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

Такая ясность обычно дешевле героического ночного исправления. Пользователь видит не отдельные сервисы и не красивые диаграммы. Он видит, выполнилась ли его задача. И архитектура должна помогать этому ответу оставаться «да» даже в неидеальный день.

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