Обнаружение фрода на edge: Cloudflare Workers + tracio.ai

Классическое обнаружение фрода происходит на уровне приложения: запрос приходит на сервер, вы обращаетесь к API обнаружения фрода, ждёте ответ и лишь потом решаете, пропустить его или заблокировать. Этот round-trip добавляет 50–200 мс задержки к каждому запросу — приемлемо для загрузки страниц, но болезненно для API-эндпоинтов, AJAX-вызовов и взаимодействий в реальном времени.

А что, если принимать решение по фроду ещё до того, как запрос дойдёт до origin-сервера? Именно это даёт edge-вычисления, и Cloudflare Workers — платформа, на которой мы демонстрируем этот подход.

Архитектура

Схема состоит из трёх компонентов: JS SDK tracio.ai (@tracio/sdk) в браузере, Cloudflare Worker между клиентом и вашим origin и подписанные webhook’и tracio.ai, доставляющие полный анализ сигналов на бэкенд.

Поток работает так. JS SDK собирает сигналы устройства и во время загрузки страницы отправляет их в tracio.ai, возвращая браузеру visitorId. Ваш бэкенд получает полный результат идентификации — классификацию ботов, smart-сигналы, уверенность — через подписанный webhook и записывает вердикт в edge-кэш. Браузер добавляет visitorId в последующие API-запросы (через заголовок или cookie). Cloudflare Worker перехватывает каждый запрос, находит закэшированный вердикт для этого visitorId и принимает решение allow/block менее чем за 5 мс.

Реализация Worker

Worker держит лёгкий кэш недавних результатов проверки устройств в KV-хранилище Cloudflare, которое наполняет ваш бэкенд по мере поступления подписанных webhook’ов tracio.ai. Когда приходит запрос с заголовком visitorId, Worker проверяет кэш. Если вердикт закэширован и посетитель «чистый» (низкий bot score, нет VPN, уверенность выше порога), запрос сразу пропускается. Если вердикта ещё нет, Worker применяет вашу fallback-политику — пропустить с консервативным rate limit или выдать challenge — пока кэш, наполняемый webhook’ами, не догонит.

Ключевая идея в том, что кэш проверок наполняется проактивно. Первая загрузка страницы запускает сбор сигналов и кэширует результат. Все последующие API-вызовы от этого посетителя попадают в кэш — round-trip к tracio.ai не нужен. TTL кэша настраивается; мы рекомендуем 5 минут для эндпоинтов с высокими требованиями к безопасности и 30 минут для обычного контента.

Цифры производительности

Мы протестировали эту архитектуру у клиента, обрабатывающего 50 000 запросов в минуту через Cloudflare Workers. Результаты:

Доля попаданий в кэш: 94% (большинство запросов — от посетителей, которые уже загрузили страницу). Задержка решения на edge (попадание в кэш): 1,2 мс по медиане, 3,8 мс p99. Задержка решения на edge (промах кэша): 45 мс по медиане (включая вызов API tracio.ai). Экономия задержки origin: 120 мс по медиане на запрос (устранена проверка фрода на стороне сервера).

Доля попаданий в кэш 94% означает, что 94% решений по фроду принимаются менее чем за 4 мс на edge, без участия origin. Оставшиеся 6% — запросы первого визита, требующие полного round-trip к API.

Стратегии блокировки

Worker поддерживает три стратегии блокировки, настраиваемые по маршрутам:

Жёсткая блокировка (hard block): сразу возвращать 403 для посетителей с высоким риском (bot score > 0,9, известный фреймворк автоматизации). Мягкая блокировка (soft block): добавлять заголовки X-Tracio-Risk и оставлять решение за origin. Это удобно, когда для решения нужен контекст уровня приложения. Challenge: перенаправлять подозрительных посетителей (умеренный bot score, обнаружен VPN) на страницу проверки, требующую дополнительной верификации.

Мы рекомендуем начинать в проде с мягкой блокировки, неделю наблюдать за распределением риска, а затем включать жёсткую блокировку для однозначных случаев (известные боты, headless-браузеры, автоматизация с высокой уверенностью).

Анализ затрат

Тарификация Cloudflare Workers основана на количестве запросов и времени вычислений. При 50 тыс. запросов/минуту (2,16 млрд/месяц) Worker стоит примерно $500/месяц. Сравните с экономией задержки: устранение 120 мс проверки фрода на стороне origin снижает загрузку CPU серверов на 15–20% — это обычно экономит на вычислениях больше, чем стоит сам Worker.

Настоящая ценность — в предотвращении фрода: перехват ботов и мошеннических запросов до того, как они потребят ресурсы origin, соединения с БД и вызовы нижестоящих API. Один клиент сократил число origin-серверов с 12 до 8 после внедрения детекции фрода на edge — боты, потреблявшие 30% его вычислений, попросту не доходили до origin.