Где проходит грань между сбоем и отказом?

Карта не прошла на кассе. Кассир пробует ещё раз и говорит: «Извините, недостаточно средств». Вы слышите именно это. Хотя на самом деле у терминала просто пропала связь с банком, а денег на карте достаточно.

На самом деле это два разных сценария: банк реально отказывает или просто сбоит терминал. Здесь сработал второй — банк вообще ни при чём, деньги просто не прошли по технической причине.

Разницу видит только тот, кто знает, куда смотреть.

Тот же вопрос в юридическом продукте

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

Реестр может ответить два принципиально разных «нет».

Юридический отказ. Реестр проверил данные, и препятствие действительно есть.
Технический сбой. Реестр недоступен или отвечает с ошибкой, а система восприняла тишину как отрицательный ответ.

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

Если продукт не различает эти два «нет», человек получает уверенный юридический вывод там, где на самом деле произошёл сетевой сбой.

Почему это остаётся слепой зоной для разработчиков?

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

Разработчик видит код и базы данных. Его зона ответственности — прошёл ли запрос технически. Смысл ответа реестра для дела клиента остаётся за скобками.

Молчание сервера — это одна ситуация. Мотивированный отказ реестра — совсем другая. И дальше пользователя нужно вести по-разному.

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

Чем это опасно на практике?

Человек, который обращается к такому сервису, обычно уже в стрессе: долги, суд, сжатые сроки.

Услышав «вам не положено», он с высокой вероятностью просто уходит: откладывает решение проблемы, ищет более дорогой обходной путь или опускает руки.

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

Ошибка при этом молчит: никто не видит её в логах как явный сбой, а снаружи всё выглядит как обычная, штатная проверка.

Что здесь должна делать архитектура?

Повторные запросы, защитное отключение при массовых сбоях (circuit breaker) и честный запасной ответ вместо угадывания (fallback) — стандартные инженерные паттерны, изобретать новую технологию для них не нужно.

Задача в другом. Показать команде: одни ответы реестра юридически значимы, другие — просто технический шум.

Система обязана различать три состояния:

Подтверждённый положительный ответ реестра.
Подтверждённый отрицательный ответ реестра.
Реестр не ответил или ответил не по существу — это отдельный самостоятельный случай со своим сценарием.

Реестры сами иногда путают эти состояния. У хорошо спроектированного интерфейса обмена данными (API) пустой результат — это нормальный, законный ответ: записей действительно нет.

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

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

Какой вариант безопасный? Централизованная проверка доступности реестра (Healthcheck) раз в несколько минут через отдельный лёгкий технический адрес (эндпоинт), с кэшированием текущего статуса. Пользовательские запросы просто читают этот статус, не создавая для него дополнительной нагрузки.

При третьем состоянии система обязана честно показать пользователю: «Мы не смогли проверить это прямо сейчас».

Когда ждать нельзя. Мягкое «подождите, идёт проверка» может быть опаснее прямого отказа, если у пользователя горит процессуальный срок — например, на подачу иска или заявления.

Уточнять у него это напрямую — лишний шаг, который стоит конверсии.

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

Правильнее развести их по времени. Сначала система просто пробует снова в фоне, не привлекая к этому внимания.

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

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

Чек-лист: что спросить у своей команды

Как система отличает «сервер недоступен» от «сервер ответил отказом»? Ответ «мы это не разделяли» — первый тревожный звонок.
Что видит пользователь при сбое реестра? Готовый юридический вывод — плохой знак. Честное «проверяем ещё раз» — правильная реакция.
Есть ли повторные попытки и агрегированная эскалация на человека? Без повторных попыток любой сбой реестра превращается в ложный отказ. Если эскалация не агрегирована, она превращается в лавину одинаковых заявок на живых людей.

Часто задаваемые вопросы

Это же должно быть очевидно любому разработчику? Очевидно постфактум, когда кто-то уже это сформулировал.

На практике команда обычно старается, чтобы код не падал и работал быстро. Юридический вес конкретного кода ошибки внешнего реестра при этом остаётся за кадром.

Это же просто повторные попытки (Retry Policy) и защитное отключение (Circuit Breaker) под другим названием? Сами по себе — да, это стандартные инженерные паттерны, и здесь не нужно изобретать велосипед.

Технически реализовать повтор запроса несложно. Гораздо важнее решить, кто в команде определит юридическое значение каждой ветки ответа реестра и распишет, что делать в каждом случае.

Это редкий случай. Стоит ли ради него усложнять систему? Недоступность государственных реестров — это регулярная, ожидаемая часть их работы.

Если продукт вообще интегрируется с внешними базами, рано или поздно он столкнётся с этим сценарием. Разработчик либо заметит проблему ещё до запуска, либо её увидит пользователь — уже после.

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

От точной формулировки этого сообщения зависит, поймёт ли пользователь, что на самом деле произошло. Это уже часть юридической логики продукта. Простым оформлением экрана это не назвать.

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

Этим занимается формат Core Architecture & Triage Logic: он проектирует такую логику с нуля.