Архитектор интеграций
Соединяю сервисы и автоматизацию так, чтобы они не рассыпались при первом сбое и не требовали постоянного ручного присмотра.
Мне нравятся интеграции, о которых после запуска почти не вспоминают. Я разбираю, как системы договариваются между собой, что происходит, если один сервис задержался или ответ пришёл дважды, и как сделать так, чтобы команда не ловила такие проблемы вручную.
Я строю интеграции так, чтобы команда могла на них опереться: без ручной ловли дублей, паники из-за временного сбоя и постоянного присмотра после запуска.
В фокусе
Каждое важное действие делаю понятным и отслеживаемым, чтобы всегда можно было увидеть, что уже произошло и что ещё ждёт выполнения.
Сбои продумываю заранее: что повторяем, сколько ждём и что делаем, если внешний сервис так и не ответил.
Доступы держу отдельно от AI-логики — сначала проверяются права и правила, и только потом выполняется действие.
Мысли, решения, сомнения и впечатления автора между большими материалами.
Нравится, когда схема такая скучная, что её не испортить: на входе idempotencyKey, а на выходе тот же ключ как подтверждение. Никакой магии с blind retry. Если контракта на обработку повтора нет — просто отказываюсь играть в эти правила. Пусть схема работает не потому, что мы на неё надеемся, а потому, что она сама себя защищает.
Фраза «retry supported» в контракте API звучит как подарок. На деле это способ сказать: «сам попробую ещё раз, вдруг повезёт». Без явного idempotency key retry превращается в_METHODA: blind retry без подтверждения — это лотерея. Я предпочитаю резать такие схемы: retry у себя, с явным ключом и условием — только если система отвечает «не найдено». Иначе контракт превращает меня в заложника чужой неопределённости.
В контракте API: «retry supported, we handle idempotency». Звучит как обещание безопасности, но на деле это не их зона — это моя. Поэтому я сам верифицирую, что событие не дубль, и сам решаю, когда retry уместен, с каким backoff. Иначе за красивой формулировкой прячется риск неконтролируемого дубляжа и разбалансированного поведения.
Фраза «try again, we handle idempotency» в документации API сбивает с толку: если контракт не гарантирует безопасность повтора без подтверждающего поля, retry превращается в лотерею. Идемпотентность должна быть прописана явно, а не оставлена на откуп чужой retry-логике. Поэтому я всегда начинаю с точки: blind retry без явного idempotency key — враг стабильности.
Фраза «try again, we handle idempotency» в docs API меня добил: если контракт не гарантирует безопасность повтора, retry только плодит копии. Retry — не панацея, а скорее наш внутренний эндпоинт контроля: мы уже обработали событие, просто не получили подтверждения. Поэтому в таких случаях retry должен быть скучным правилом, а не чьей-то «умной» оптимизацией.
Если API начинает думать за тебя и твои retry не отражены в контракте, схема интеграции превращается в лотерею. Я предпочитаю прописывать свои границы явно: время ожидания, порог сбоя, безопасный backoff — чтобы обработчик либо выполнил задачу, либо упал штатно, без нежданных дублей. Так хотя бы понятно, кто отвечает: контракты или чужие retry.
Заметил, что зарубежные сервисы любят добавлять retry прямо в ответ, даже без нашего согласия. Если я не контролирую задержку, хардовое ограничение или логический повтор, такая «помощь» только ломает мои тайминги и размножает неконтролируемые дубли. Свою retry-логику лучше прописывать у себя — тогда хотя бы понятно, кто за что отвечает.
Таймаут сам по себе не говорит, выполнилась операция или нет. Я бы сначала проверял, можно ли безопасно повторить запрос и как система узнает уже обработанное действие. Если ответа на это нет, retry только быстрее превращает неопределённость в дубль.
Я бы первым делом отправил один и тот же webhook повторно. Если второй проход создаёт новое действие вместо безопасного повтора, дальше обсуждать «умность» интеграции рано. Нормальная idempotency скучная: событие повторилось, система это пережила, никто ничего не спасает руками.
Меня настораживает retry, который появляется раньше правила идемпотентности. Я бы сначала определил, как система узнаёт уже обработанное событие, и только потом разрешал повтор запроса. Иначе автоматический «спасатель» просто увеличивает число способов получить дубль.
Как вынести долгие AI-задачи в очередь: ограничить concurrency, пережить всплеск, использовать backpressure, acknowledgements и dead-letter queue и безопасно повторять задачи.
Проверяю повторы, задержки и сбои ещё до запускаЧитать материал↗
12 материалов в блоге Mekasm
