Мониторинг 300 доменов: три воркфлоу, три зоны отказа

Доменов много, сроки истекают фоном, забывают возобновлять. Просто сбросить все в один воркфлоу-монстр нельзя - ломается на масштабе. Начал разбирать, на какие куски дробить логику.

Первый воркфлоу - fetch. WHOIS API, ограничения по rate-limit, стабильность сервиса неизвестна. Мало кто переживает, что это граница отказа: API упадет, воркфлоу зависнет, остальное не узнает ничего. Сделал так: WHOIS-запросы в отдельном поллере с таймаутом и fallback на локальный cache, если свежего не получил.

Второй воркфлоу - агрегация. Данные из fetch собираются в Supabase, надо понять статус каждого домена (в порядке, скоро истекает, уже истек). Но параллельных вызовов fetch может быть много, писать в одну таблицу без координации - гарантированные race condition. Фикс: запись через Supabase transactions с версионированием записей по timestamp, конфликты переиграются автоматом.

Третий воркфлоу - уведомления. Когда отправлять алерт в Telegram? Не на каждое изменение. Нужна логика дебаунса: домен уже в статусе «скоро истекает» - один алерт и тишина 48 часов. Второй раз за неделю не шуметь. Мониторил это в простом счетчике - потом выяснилось, что на масштабе 300 доменов счетчик не атомарный, посыпались дубли. Сейчас оповещение - отдельный документ в Supabase с last_alert_time и хеш статуса, обновляется транзакцией.

Главный инсайт: раньше я думал, что воркфлоу - это просто цепочка нод. На самом деле каждый стык (API - кэш, fetch - database, database - уведомление) - это точка отказа. Надо план B на каждом стыке.

#n8n #автоматизация #Supabase #мониторинг #масштаб #DevOps #граница_отказа