A cota grátis do Workers não é suficiente? 7 dicas para fazer 100 mil requisições durarem o mês

No mês passado, montei um serviço de hospedagem de imagens com Workers e armazenamento no R2. Parecia perfeito. Em menos de 3 dias, porém, recebi um e-mail da Cloudflare avisando que minha cota gratuita estava quase esgotada.

Fiquei sem entender: o limite não era de 100 mil requisições por dia? Quanto tráfego um serviço tão pequeno poderia ter? Abri o Analytics e vi uma média de 120 mil requisições diárias. Como isso era possível, se eu só tinha enviado algumas dezenas de imagens?

Passei dois dias estudando a documentação e as discussões da comunidade até entender as armadilhas da cobrança do Workers. Subrequisições, leituras no KV e acertos de cache: cada detalhe estava consumindo minha cota sem que eu percebesse.

A boa notícia é que, depois de entender as regras, apliquei algumas otimizações e reduzi o volume diário de 120 mil para 30 mil requisições. Agora a cota gratuita é suficiente e ainda sobra 30%. Neste artigo, compartilho o que funcionou na prática para ajudar você a economizar os US$ 5 mensais do plano pago.

Não se engane: as “100 mil requisições” do Workers não são o que parecem

Para ser sincero, a expressão “100 mil requisições por dia” na documentação da Cloudflare pode causar confusão. No começo, achei que o limite seria atingido quando meu Worker recebesse 100 mil acessos. O cálculo não funciona bem assim.

Fato 1: subrequisições não são cobradas separadamente, mas têm limite de quantidade

Chamadas a outras APIs com fetch(), leituras do R2 e consultas ao KV dentro do Worker são chamadas de subrequisições. A boa notícia é que elas não são cobradas separadamente. A má notícia é que o plano gratuito permite apenas 50 subrequisições por requisição, enquanto o pago chega a 1.000.

Por exemplo: o usuário acessa o endereço do seu serviço de imagens (1 requisição cobrada), o Worker consulta o KV para validar a permissão (1 subrequisição) e busca a imagem no R2 (1 subrequisição). Embora existam 2 subrequisições, apenas 1 requisição é cobrada.

Se você mantém um serviço agregador que consulta 10 APIs em uma única chamada, isso representa 10 subrequisições. O limite de 50 do plano gratuito parece alto, mas pode ser alcançado facilmente em um projeto real.

Fato 2: as 100 mil requisições são um limite por conta, não por Worker

Este ponto é fácil de confundir. No começo, achei que poderia distribuir o tráfego entre vários Workers, mas descobri que o limite de 100 mil vale para a conta inteira. Mesmo que você registre 10 Workers, todos juntos ainda terão apenas 100 mil requisições.

Quer contornar a cota criando vários Workers? Não funciona. Pessoas da comunidade já testaram, e a Cloudflare aplica o limite por conta. Para ultrapassá-lo, é preciso pagar ou reduzir o número de requisições.

Fato 3: leituras e gravações no KV e operações da Cache API também contam

Este é o ponto mais fácil de ignorar. Cada KV.get() feito pelo Worker, embora não entre no limite de subrequisições, consome operações. Se o Worker consulta o KV para validar permissões em todo acesso, cada visita do usuário gera mais uma operação no KV.

O mesmo vale para a Cache API. Embora o cache reduza chamadas à origem, as próprias operações match() e put() também têm custo.

As 3 armadilhas mais comuns

Foram justamente estas armadilhas que fizeram meu volume de requisições explodir:

1. Armadilha 1: o proxy reverso envia subrequisições sempre e não usa cache
   Criei um serviço intermediário para uma API e fazia fetch() da API original em toda chamada. Não pensei em cache, então cada requisição do usuário gerava uma subrequisição. Depois de adicionar a Cache API, alcancei 80% de acerto e cortei pela metade o número de requisições.
2. Armadilha 2: leituras frequentes no KV sem conhecer o parâmetro cacheTtl
   No serviço de imagens, cada arquivo exigia um KV.get() para verificar a permissão. Eu não sabia que era possível definir cacheTtl para armazenar os dados do KV nos pontos de presença. Depois de mudar para cacheTtl: 600 (10 minutos), as leituras no KV caíram 70%.
3. Armadilha 3: cada salto de uma cadeia de redirecionamentos conta
   Em um encurtador de links, eu retornava redirecionamentos 302. Depois descobri que, em uma cadeia com três saltos (A→B→C→destino), cada salto conta como uma subrequisição. Passei a retornar diretamente o endereço final e economizei 2 contagens.

Juntas, essas armadilhas explicam por que passei do limite de 100 mil e cheguei a 120 mil. Se sua cota também não é suficiente, verifique primeiro se você caiu em alguma delas.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

7 técnicas para fazer a cota gratuita durar mais um mês

Depois de entender as regras de cobrança, testei várias formas de otimização. Estas 7 técnicas tiveram o efeito mais claro na prática e não são difíceis de implementar.

Técnica 1: use bem o cache para reduzir em 80% as requisições repetidas

Foi a mudança que trouxe resultado mais rápido nos meus testes. Muitos projetos com Workers não precisam recalcular tudo em tempo real e podem armazenar os resultados em cache.

Antes da otimização, cada acesso a uma imagem passava pelo fluxo completo: validação→leitura do R2→resposta. Depois, adicionei a Cache API:

const cache = caches.default;
const cacheKey = new Request(request.url, request);
// Consulte o cache primeiro
let response = await cache.match(cacheKey);
if (response) {
  return response; // Acerto no cache: retorne diretamente
}
// Falha no cache: processe a requisição
response = await handleRequest(request);
// Defina o cache (imagens estáticas por 1 dia)
response = new Response(response.body, {
  ...response,
  headers: {
    ...response.headers,
    'Cache-Control': 'public, max-age=86400',
  },
});
await cache.put(cacheKey, response.clone());
return response;

Após a mudança, a taxa de acerto chegou a 85%. Das 120 mil requisições diárias anteriores, só 18 mil passaram de fato pela lógica do Worker, uma economia de 102 mil.

Técnica 2: três medidas para otimizar o KV

O KV é uma das formas de armazenamento mais usadas com Workers, mas também pode responder por grande parte das operações. Resumi a otimização em 3 pontos:

1. Aumente o parâmetro cacheTtl
   Por padrão, o KV mantém os dados em cache no ponto de presença por 60 segundos. Se eles mudam pouco, aumente esse valor:

   // Antes da otimização
   const value = await KV.get('key');
   // Depois da otimização (cache por 10 minutos)
   const value = await KV.get('key', { cacheTtl: 600 });

   Meus dados de validação de permissões só mudavam a cada meia hora. Com cacheTtl: 1800, as leituras no KV caíram 70%.
2. Use a Cache API para armazenar resultados do KV
   Se os dados mudam ainda menos, como arquivos de configuração ou listas de bloqueio, você pode adicionar outra camada de cache no Worker:

   const cacheKey = `kv-cache:${key}`;
   let cached = await caches.default.match(cacheKey);
   if (!cached) {
     const value = await KV.get(key);
     cached = new Response(value);
     await caches.default.put(cacheKey, cached.clone());
   }
   return cached.text();

3. Use waitUntil para gravações não bloqueantes
   Se você precisa gravar no KV, mas não precisa esperar o resultado, use waitUntil para não bloquear a resposta:

   // Retorne a resposta sem esperar a gravação no KV terminar
   event.waitUntil(KV.put('key', 'value'));
   return new Response('OK');

Com as três medidas, minhas operações no KV caíram de uma média de 30 mil para 8 mil por dia.

Técnica 3: reduza subrequisições desnecessárias

Em muitos casos, é possível eliminar subrequisições.

Eu mantinha um serviço agregador que consultava 5 APIs externas e combinava os resultados. Cada requisição gerava 5 subrequisições. Depois, mudei o fluxo:

• Os resultados de APIs com alta frequência ficam em cache por 5 minutos
• Os resultados de APIs com baixa frequência ficam no KV por 24 horas
• Quando possível, os dados são pré-processados e armazenados no R2

Após a otimização, 80% das requisições deixaram de gerar qualquer subrequisição e passaram a ser respondidas diretamente pelo cache.

Técnica 4: use Request.cache para controlar o comportamento do cache

Em novembro de 2024, a Cloudflare adicionou a propriedade Request.cache, que permite um controle mais preciso:

// Ignore o cache (adequado para dados sensíveis)
const response = await fetch(url, { cache: 'no-store' });
// Use a política padrão de cache
const response = await fetch(url, { cache: 'default' });

Para imagens privadas de usuários, uso cache: 'no-store' para impedir que a CDN as armazene. Para imagens públicas, uso default e deixo a Cloudflare otimizar automaticamente.

Técnica 5: otimize as cadeias de redirecionamento

Se o Worker retorna redirecionamentos (302/301), lembre-se de que cada salto da cadeia conta como uma subrequisição.

Antes da otimização, meu encurtador de links fazia isto:

// Antes: retorne um redirecionamento 302
return Response.redirect(targetUrl, 302);

Depois da otimização:

// Depois: armazene o endereço de destino em cache e reduza redirecionamentos
const cached = await cache.match(shortUrl);
if (cached) {
  return cached; // Retorne diretamente o endereço final armazenado em cache
}

Para links com vários saltos, como bit.ly → t.co → endereço final, armazene diretamente o destino final para evitar percorrer a cadeia em todo acesso.

Técnica 6: monitore a distribuição das requisições e encontre os grandes consumidores

O Analytics da Cloudflare é gratuito, então vale a pena usá-lo.

Percebi um padrão: 80% do volume de requisições geralmente vem de 20% dos caminhos. No Workers Analytics, você pode ver:

• Quais caminhos recebem mais requisições
• Quais caminhos têm baixa taxa de acerto do cache
• Quais caminhos levam mais tempo

Identifique os caminhos com maior volume e otimize-os de forma direcionada. No meu caso, descobri que o endpoint de verificação /api/status era chamado 100 vezes por minuto pelo serviço de monitoramento e respondia por 15% do volume diário. Depois de adicionar um cache de 60 segundos, economizei 15 mil requisições por dia.

Técnica 7: execute tarefas não urgentes em horários programados

Workers oferece Cron Triggers para executar tarefas periodicamente. Se uma tarefa não precisa ocorrer em tempo real, como estatísticas, limpeza ou aquecimento de cache, você pode executá-la fora dos horários de pico.

Meu serviço de imagens tinha um recurso que contabilizava acessos a cada hora. Antes, cada visita gravava no contador do KV. Depois, mudei para:

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

• Contabilizar as visitas apenas na memória, sem gravar no KV
• Consolidar os dados uma vez por hora com um Cron Trigger

Assim, as gravações frequentes no KV viraram uma única operação em lote por hora. A média diária caiu de 20 mil gravações para 24.

Caso real: de 120 mil para 30 mil requisições diárias no serviço de imagens

Depois de tantas técnicas, talvez você queira saber qual é o resultado quando elas são combinadas. A seguir, mostro toda a otimização do meu serviço de hospedagem de imagens.

Contexto do projeto

É um serviço simples com a seguinte stack:

• Cloudflare Workers para processar requisições
• R2 para armazenar os arquivos de imagem
• KV para armazenar metadados e permissões das imagens
• Cerca de 2.000 acessos a imagens por dia, considerando o tráfego real de usuários

No terceiro dia após o lançamento, recebi um alerta da Cloudflare: eram 120 mil requisições diárias, perto do limite da cota gratuita.

Diagnóstico do problema

Passei meio dia usando o Analytics e revisando o código até encontrar 3 problemas principais:

1. Toda requisição de imagem consultava o KV
   Em cada acesso, o Worker fazia KV.get() para consultar os metadados, como nome do arquivo, tamanho e autor do envio. Dois mil acessos representavam 2.000 leituras no KV. Como esses metadados quase não mudavam, não havia motivo para consultá-los sempre.
2. Não havia cache no navegador
   Eu não tinha definido Cache-Control nos cabeçalhos da resposta. Quando o usuário atualizava a página, o navegador solicitava tudo de novo. Se o mesmo usuário carregasse a mesma imagem 10 vezes, o Worker seria chamado 10 vezes.
3. As miniaturas eram geradas em tempo real
   A página de listagem exibia miniaturas que o Worker recortava em tempo real. Uma página com 30 imagens gerava 30 requisições de processamento. Bastava o usuário navegar por algumas páginas para o volume disparar.

Esses três problemas transformaram 2.000 acessos reais em 120 mil chamadas ao Worker.

Plano de otimização

Resolvi os 3 problemas por ordem de prioridade:

Etapa 1: otimização do cache do KV (resultado mais rápido)

Adicionei o parâmetro cacheTtl às leituras do KV:

// Antes da otimização
const metadata = await IMAGE_KV.get(imageId);
// Depois da otimização
const metadata = await IMAGE_KV.get(imageId, {
  cacheTtl: 600  // Cache por 10 minutos
});

Resultado: as leituras no KV caíram de 2.000 para cerca de 300 por dia (-85%).

Etapa 2: adicionar cache no navegador

Adicionei cabeçalhos de cache às respostas de imagem:

return new Response(imageData, {
  headers: {
    'Content-Type': 'image/jpeg',
    'Cache-Control': 'public, max-age=86400',  // Cache por 1 dia
    'CDN-Cache-Control': 'public, max-age=2592000'  // Cache da CDN por 30 dias
  }
});

Resultado: os acessos repetidos caíram 60%, e o volume passou de 120 mil para 48 mil requisições.

Etapa 3: pré-gerar as miniaturas

Em vez de gerar as miniaturas em tempo real, passei a criá-las no envio e armazená-las no diretório thumbnails/ do R2:

// Gere a miniatura durante o envio
const thumbnail = await generateThumbnail(image);
await R2.put(`thumbnails/${imageId}`, thumbnail);
// Leia diretamente durante o acesso
const thumbnail = await R2.get(`thumbnails/${imageId}`);

Resultado: as requisições de miniaturas deixaram de acionar a lógica de processamento do Worker, e o volume caiu de 48 mil para 32 mil.

Etapa 4: camada de cache do Worker

Por fim, adicionei a Cache API à resposta inteira:

const cache = caches.default;
let response = await cache.match(request);
if (response) return response;
// Processe a requisição...
await cache.put(request, response.clone());
return response;

Resultado: a taxa de acerto do cache chegou a 78%, e o volume se estabilizou em cerca de 30 mil requisições por dia.

Resultado da otimização

O serviço está funcionando de forma estável há 2 meses, com 30 mil a 40 mil requisições diárias, e a cota gratuita é mais do que suficiente. Considerando o plano pago de US$ 5 por mês, a economia anual é de US$ 60.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

Lições aprendidas

Olhando para trás, resumo a experiência em alguns pontos:

1. Encontre o gargalo antes de otimizar: não otimize às cegas; use o Analytics para localizar o problema real
2. Cache é fundamental: 80% do resultado veio do cache do navegador, da CDN e do Worker
3. Use o KV com cuidado: sempre defina cacheTtl para dados que podem ser armazenados em cache e não consulte em tempo real o que puder ser pré-calculado
4. Otimize aos poucos: fiz a otimização em 4 etapas e consegui observar o resultado de cada uma, em vez de mudar tudo de uma vez

Pagar ou otimizar? Faça as contas

Talvez você esteja pensando se vale mais a pena gastar tempo otimizando ou simplesmente migrar para o plano pago. Eu também tive essa dúvida, mas as contas deixaram a resposta mais clara.

Comparação entre o plano gratuito e o pago

Pelos números, o plano pago parece atraente: triplica o volume diário e amplia em 20 vezes o limite de subrequisições. Mas a questão é se você realmente precisa dele.

Quando migrar para o plano pago?

Resumi 3 situações em que recomendo pagar diretamente:

1. O volume diário permanece acima de 100 mil
   A palavra importante é “permanece”. Um pico ocasional pode ser resolvido com otimização. Mas, se o volume fica acima do limite durante uma semana inteira, o negócio realmente cresceu e pagar traz mais tranquilidade.
2. Você precisa de muitas subrequisições
   Em crawlers, agregadores ou gateways de API, uma única requisição pode chamar mais de 10 APIs externas. Se o limite gratuito de 50 não for suficiente, há pouco espaço para otimizar, e o limite pago de 1.000 é mais adequado.
3. Em um projeto comercial, estabilidade é mais importante do que custo
   Se o projeto é para um cliente ou é seu produto comercial, não tente economizar justamente na cota gratuita. O SLA do plano pago oferece mais segurança e permite abrir chamados. A estabilidade obtida por US$ 5 vale muito mais do que essa economia.

Onde está o limite da otimização?

Por outro lado, há situações em que otimizar é perda de tempo:

1. Otimização excessiva torna o código complexo
   Se você cria muita lógica de cache, scripts de pré-processamento e tarefas agendadas só para economizar requisições, o código fica difícil de manter. Nesse ponto, seu tempo pode valer muito mais que US$ 5.
2. Você já chegou ao limite da otimização
   Se adicionou todo o cache possível, otimizou o restante e ainda não é suficiente, o problema é o volume do negócio. Não insista: pague quando for necessário.
3. Custo de tempo versus US$ 5
   Calcule seu valor por hora. Se a otimização levar 3 horas e sua hora valer mais de 20, pagar diretamente compensa mais.

Minha recomendação:

• Projetos pessoais e de estudo: otimize primeiro; você economiza e aprende
• Equipes pequenas e produtos em fase inicial: leve a otimização ao limite antes de pagar
• Projetos comerciais e de clientes: pague diretamente e não tente economizar nisso

Ainda é preciso otimizar depois de contratar o plano pago?

Sim. Embora a cota do plano pago seja maior, as regras de cobrança são as mesmas. Sem otimização, você também pode esgotar as 10 milhões de requisições.

Depois que a franquia do plano pago termina, o excedente custa US$ 0,50 por milhão de requisições. Com uma média diária de 1 milhão, seriam US$ 15 de excedente por mês, mais US$ 5 de base, totalizando US$ 20 por mês. É aí que a otimização mostra seu valor.

Conclusão

Depois de tudo isso, o ponto central é simples: entenda como o Workers cobra e aplique as técnicas corretas.

A cota gratuita de 100 mil requisições do Workers parece grande, mas pode acabar rapidamente. Na maioria dos casos, o problema não é um volume de negócio alto, e sim a falta de otimização.

Meu serviço de imagens é um bom exemplo: apenas 2.000 acessos reais geravam 120 mil requisições. Com cache, otimização do KV e pré-processamento, o total caiu para 30 mil, deixando a cota suficiente e ainda com folga.

Se sua cota também está acabando, siga estes passos:

1. Abra o Workers Analytics e veja quais caminhos estão consumindo a cota
2. Comece pelo cache e pelo KV, que trazem os resultados mais rápidos
3. Verifique se você caiu em uma das 3 armadilhas deste artigo: subrequisições, KV cacheTtl e cadeias de redirecionamento
4. Experimente as 7 técnicas em conjunto
5. Se a cota ainda não bastar depois de toda a otimização, considere o plano pago

Um último lembrete: a Cloudflare é uma empresa comercial, e a cota gratuita deve ser usada de forma razoável. Tentar explorar o serviço em excesso pode causar limitação de velocidade ou até bloqueio da conta. O objetivo da otimização é usar os recursos com eficiência, não procurar brechas.

Se este artigo ajudou você a economizar US$ 5, curta ou compartilhe com outras pessoas que também usam Workers. Assim, todos aproveitam melhor a cota gratuita.