Timeout ≠ операция не выполнена.

Это одна из вещей, которую системному аналитику лучше понять как можно раньше. Представим обычный перевод. Наша система отправила запрос на списание денег. Ответ не пришёл вовремя — получили timeout. Самое простое решение: отправить запрос ещё раз. И вот здесь начинается самое интересное. Первая операция могла успешно выполниться, а потерялся только ответ. Повторный запрос без дополнительных проверок — и у клиента потенциально два списания вместо одного. Поэтому при проектировании интеграции мне важно описать не только happy path: отправили запрос → получили 200 → сохранили статус Гораздо важнее заранее ответить на другие вопросы: — есть ли у операции уникальный идентификатор; — поддерживает ли принимающая система идемпотентность; — что делаем после timeout; — можем ли запросить фактический статус операции; — сколько раз и с каким интервалом повторяем запрос; — когда переводим операцию в «требуется ручной разбор»; — как сверяем наши данные с данными внешней системы. В итоге у хорошей интеграции обычно существует не только SUCCESS и ERROR, но и состояние вроде UNKNOWN / STATUS_UNDEFINED. И это не техническая мелочь. Это разница между системой, которая просто работает в идеальных условиях, и системой, которая предсказуемо ведёт себя, когда что-то пошло не по плану. Для меня в этом и заключается одна из самых интересных частей системного анализа: найти такие сценарии раньше, чем их найдёт production.