Detecção de fraude na borda: Cloudflare Workers + tracio.ai
Execute a validação de impressão digital de dispositivo em Cloudflare Workers antes que as requisições cheguem à sua origem. Decisões de fraude na borda em menos de 5ms.
A detecção de fraude tradicional acontece na camada de aplicação: a requisição chega ao seu servidor, você consulta sua API de detecção de fraude, espera a resposta e então decide se permite ou bloqueia. Essa ida e volta adiciona de 50 a 200ms de latência a cada requisição — aceitável para carregamentos de página, mas doloroso para endpoints de API, chamadas AJAX e interações em tempo real.
E se você pudesse tomar a decisão de fraude antes que a requisição chegue ao seu servidor de origem? É isso que a computação de borda permite, e o Cloudflare Workers é a plataforma que usamos para demonstrar esse padrão.
A arquitetura
A configuração tem três componentes: o JS SDK da tracio.ai (@tracio/sdk) rodando no navegador, um Cloudflare Worker posicionado entre o cliente e sua origem, e webhooks assinados da tracio.ai entregando a análise completa de sinais ao seu backend.
O fluxo funciona assim: o JS SDK coleta os sinais do dispositivo e os envia à tracio.ai durante o carregamento da página, retornando um visitorId ao navegador. Seu backend recebe o resultado completo da identificação — classificação de bot, smart signals, confiança — por meio de um webhook assinado e grava o veredito em um cache de borda. O navegador inclui o visitorId nas requisições de API subsequentes (via header ou cookie). O Cloudflare Worker intercepta cada requisição, busca o veredito em cache para aquele visitorId e toma uma decisão de permitir/bloquear em menos de 5ms.
Implementação do Worker
O Worker mantém um cache leve de resultados recentes de verificação de dispositivos usando o armazenamento KV da Cloudflare, populado pelo seu backend à medida que os webhooks assinados da tracio.ai chegam. Quando uma requisição chega com um header visitorId, o Worker verifica o cache. Se o veredito estiver em cache e o visitante estiver limpo (pontuação de bot baixa, sem VPN, confiança acima do limite), a requisição passa imediatamente. Se ainda não houver veredito em cache, o Worker aplica sua política de fallback — deixar passar com um limite de taxa conservador, ou desafiar — até que o cache alimentado por webhooks se atualize.
A percepção crítica é que o cache de verificação é populado de forma proativa. O primeiro carregamento de página dispara a coleta de sinais e armazena o resultado em cache. Todas as chamadas de API subsequentes daquele visitante acertam o cache — sem necessidade de ida e volta à tracio.ai. O TTL do cache é configurável; recomendamos 5 minutos para endpoints de alta segurança e 30 minutos para conteúdo geral.
Números de desempenho
Fizemos benchmark dessa arquitetura com um cliente processando 50.000 requisições por minuto através do Cloudflare Workers. Resultados:
Taxa de acerto de cache: 94% (a maioria das requisições vem de visitantes que já carregaram uma página). Latência da decisão na borda (acerto de cache): 1,2ms de mediana, 3,8ms no p99. Latência da decisão na borda (falha de cache): 45ms de mediana (inclui a chamada de API à tracio.ai). Economia de latência de origem: 120ms de mediana por requisição (verificação de fraude do lado do servidor eliminada).
A taxa de acerto de cache de 94% significa que 94% das decisões de fraude acontecem em menos de 4ms na borda, sem nenhum envolvimento da origem. Os 6% restantes são requisições de primeira visita que exigem uma ida e volta completa à API.
Estratégias de bloqueio
O Worker suporta três estratégias de bloqueio, configuráveis por rota:
Bloqueio rígido: retornar 403 imediatamente para visitantes de alto risco (pontuação de bot > 0,9, framework de automação conhecido). Bloqueio suave: adicionar headers X-Tracio-Risk e deixar a origem decidir. Isso é útil quando você quer contexto de nível de aplicação para a decisão. Desafio: redirecionar visitantes suspeitos (pontuação de bot moderada, VPN detectada) para uma página de desafio que exige verificação adicional.
Recomendamos começar com o bloqueio suave em produção, monitorar a distribuição de risco por uma semana e então habilitar o bloqueio rígido para casos evidentes (bots conhecidos, navegadores headless, automação de alta confiança).
Análise de custo
O preço do Cloudflare Workers é baseado em requisições e tempo de computação. A 50 mil requisições/minuto (2,16 bilhões/mês), o custo do Worker é de aproximadamente US$ 500/mês. Compare isso com a economia de latência: eliminar 120ms de verificação de fraude no lado da origem reduz o uso de CPU do servidor em 15-20%, o que normalmente economiza mais do que o custo do Worker em computação.
O valor real está na prevenção de fraudes: capturar bots e requisições fraudulentas antes que consumam recursos de origem, conexões de banco de dados e chamadas de API downstream. Um cliente reduziu sua contagem de servidores de origem de 12 para 8 depois de implementar a detecção de fraude baseada em borda — os bots que consumiam 30% da sua computação nunca chegaram à origem.