Como escolher fila de mensagens: SQS, Cloudflare Queues ou QStash

1. Decida primeiro quem inicia a entrega#

A diferença mais importante entre filas não é o preço: é quem abre a conexão. No modelo pull, os seus workers pedem mensagens quando têm capacidade e confirmam cada uma ao terminar. No modelo push, o serviço chama o seu código, normalmente via HTTP, e considera a mensagem entregue quando você responde com sucesso.

• O AWS SQS é pull: os seus consumidores chamam ReceiveMessage e depois DeleteMessage. Com long polling, a chamada espera até 20 segundos por mensagens, o que reduz respostas vazias e custo.
• O Cloudflare Queues oferece os dois: um consumidor Worker recebe lotes no modo push, ou um consumidor pull os pede via HTTP de qualquer ambiente fora dos Workers, com um token de API e um visibility timeout de 30 segundos por padrão e até 12 horas.
• O Upstash QStash é push: envia uma requisição HTTP para o seu endpoint com o corpo sem modificação e uma assinatura no header Upstash-Signature que você precisa verificar.

Pull funciona bem quando os seus workers são processos de longa duração, quando você precisa controlar a pressão sobre um banco de dados ou quer escalar consumidores pelo backlog. Push combina com funções serverless ou endpoints HTTP existentes que não deveriam manter um loop de polling. O custo de um modelo push inclui manter um endpoint público, autenticado e capaz de responder a tempo.

Documentação: AWS: short e long polling no SQS ↗ · Cloudflare: consumidores pull ↗ · Upstash: receber mensagens do QStash ↗

2. Garantias de entrega: pelo menos uma vez, ordem e deduplicação#

As três opções podem entregar uma mensagem mais de uma vez. O SQS Standard documenta entrega pelo menos uma vez (at-least-once): se um servidor que guarda uma cópia estiver indisponível na hora da exclusão, essa cópia pode voltar. O Cloudflare Queues também declara entrega pelo menos uma vez e avisa que, em raras ocasiões, uma mensagem pode ser entregue mais de uma vez. No QStash, qualquer resposta sem status 2XX dispara um retry, então um endpoint que processou mas respondeu tarde ou com erro vai receber a mensagem de novo.

A ordem é outra decisão. O SQS Standard tenta preservar a ordem de envio, mas as mensagens podem chegar ocasionalmente fora de ordem. O SQS FIFO preserva a ordem dentro de cada grupo de mensagens e não introduz duplicatas na fila quando você repete SendMessage dentro de um intervalo de deduplicação de 5 minutos, usando um MessageDeduplicationId ou deduplicação por conteúdo com SHA-256 do corpo. O QStash oferece filas com entrega FIFO uma a uma e uma deduplicação de 10 minutos por Upstash-Deduplication-Id ou por conteúdo. A documentação de garantias do Cloudflare Queues não promete ordem.

Nenhuma dessas janelas substitui a idempotência do consumidor: elas deduplicam publicações próximas, não efeitos de negócio. O guia de filas, retries e idempotência explica como projetar essa parte; aqui basta saber que você vai precisar dela com qualquer provedor.

Para se aprofundar: Filas, retries e idempotência: evite processar duas vezes

Documentação: AWS: entrega pelo menos uma vez no SQS ↗ · AWS: ordem em filas Standard ↗ · AWS: filas FIFO ↗ · AWS: deduplicação em FIFO ↗ · Cloudflare: garantias de entrega do Queues ↗ · Upstash: filas FIFO do QStash ↗ · Upstash: deduplicação no QStash ↗ · Upstash: retries do QStash ↗

3. Retenção, tamanho, atraso e throughput#

Os limites operacionais eliminam opções antes do preço. Um payload de 500 KB não cabe no Cloudflare Queues; um job agendado para daqui a uma semana não cabe no atraso do SQS; uma rajada ordenada muito grande pode esbarrar no throughput do FIFO.

No Cloudflare Queues, uma mensagem que esgota os retries é apagada da fila, a menos que você configure uma fila de mensagens com falha (DLQ). No QStash, a espera entre retries cresce de forma exponencial até um máximo de um dia. No SQS, a mensagem reaparece quando o visibility timeout expira, então esse valor precisa cobrir o seu tempo real de processamento.

A retenção é um amortecedor para incidentes: se o seu consumidor cair num feriado prolongado, 4 dias por padrão podem não bastar. Configure-a de propósito e crie alertas pela idade da mensagem mais antiga, não só pelo tamanho do backlog.

Documentação: AWS: cotas de mensagens do SQS ↗ · Cloudflare: limites do Queues ↗ · Cloudflare: batching e retries ↗ · Upstash: plano Pay as You Go ↗ · Upstash: retries do QStash ↗

4. Entenda a unidade que você paga#

Cada provedor cobra uma unidade diferente e nenhuma é exatamente uma mensagem. Por isso o comparador de filas da Codifly modela um cenário comum: 1 milhão de mensagens de 1 KiB para um consumidor, sem lotes, retries nem cotas gratuitas.

• O SQS cobra por requisição: em us-east-1, $0,40 por milhão no Standard e $0,50 por milhão no FIFO na primeira faixa, com 1 milhão de requisições grátis por mês. Toda ação conta, incluindo ReceiveMessage, DeleteMessage e ChangeMessageVisibility. Cada bloco de 64 KB do payload conta como uma requisição: uma ação com 1 MiB é cobrada como 16. Um lote de até 10 mensagens conta como uma única requisição.
• O Cloudflare Queues cobra $0,40 por milhão de operações no Workers Paid, com 1 milhão incluído por mês. Conta uma operação para cada 64 KB gravados, lidos ou apagados, e cada retry soma uma leitura. Não cobra egress nem largura de banda, mas o plano Workers Paid e a execução dos seus Workers são pagos à parte.
• O QStash cobra $1 a cada 100.000 mensagens, em que uma tentativa de entrega a um endpoint conta como uma mensagem. Um retry é outra tentativa, e publicar em um topic é cobrado uma vez por endpoint inscrito. Inclui 50 GB de transferência por mês; o excedente custa $0,05 por GB.

No cenário de referência do comparador, uma mensagem no SQS ou no Cloudflare implica três chamadas: enviar, ler e apagar. Isso dá $1,20 por milhão de mensagens no SQS Standard e no Cloudflare Queues, $1,50 no SQS FIFO e $10 no QStash. A diferença do QStash compra algo: você não opera workers de polling e ganha atrasos longos. Em nenhum dos casos o preço inclui a execução do consumidor.

Documentação: AWS: regras de cobrança do SQS ↗ · AWS: lista de preços do SQS em us-east-1 ↗ · Cloudflare: preços do Queues ↗ · Upstash: preços do QStash ↗

5. Exemplo: como retries e lotes mexem na fatura#

Premissas: 10 milhões de mensagens de 1 KiB por mês, um consumidor e 5% das mensagens (500.000) que falham uma vez e passam por um retry. Descontamos a cota gratuita de cada provedor e não incluímos computação, planos base nem transferência.

SQS Standard, sem lotes
  envio 10 M + recebimento (10 M + 0,5 M) + exclusão 10 M = 30,5 M requisições
  (30,5 M − 1 M grátis) × $0,40 por M            = $11,80

SQS FIFO, sem lotes
  (30,5 M − 1 M grátis) × $0,50 por M            = $14,75

SQS Standard, lotes completos de 10
  1 M + (1 M + 0,05 M) + 1 M = 3,05 M requisições
  (3,05 M − 1 M grátis) × $0,40 por M            = $0,82

Cloudflare Queues
  gravação 10 M + leitura (10 M + 0,5 M) + exclusão 10 M = 30,5 M operações
  (30,5 M − 1 M incluídas) × $0,40 por M         = $11,80

QStash
  10 M tentativas + 0,5 M retries = 10,5 M tentativas
  10,5 M / 100.000 × $1                          = $105,00
  com 2 endpoints inscritos em um topic: × 2     = $210,00

Essas contas trazem três lições. Primeira: no SQS, os lotes reduzem o custo quase dez vezes porque a unidade é a requisição, não a mensagem. Segunda: a Cloudflare esclarece que as operações são por mensagem, não por lote; um lote de 10 gera 10 gravações, 10 leituras e 10 exclusões. Terceira: no QStash, cada retry e cada destino adicional é uma mensagem cobrada; uma dependência fora do ar que devolve 500 durante horas vira gasto direto.

O tamanho também multiplica. Com mensagens de 100 KB, cada ação do SQS e cada leitura ou gravação do Cloudflare passa a contar como dois blocos de 64 KB. No SQS, o short polling com a fila vazia gera requisições cobradas sem mensagens; use long polling. E no SQS, cada ChangeMessageVisibility para estender um job longo é mais uma requisição.

Documentação: AWS: regras de cobrança do SQS ↗ · AWS: lista de preços do SQS em us-east-1 ↗ · Cloudflare: preços do Queues ↗ · Upstash: preços do QStash ↗

6. Qual opção combina com cada caso#

Se você já opera em uma nuvem, a integração com a identidade, a rede e a observabilidade dela costuma pesar mais que alguns centavos por milhão. Trocar de fila mais adiante é possível, mas mexe em produtores, consumidores, alertas e no tratamento de mensagens com falha.

7. Checklist para escolher a fila#

• Defina se o seu consumidor aguenta fazer polling ou se precisa receber chamadas HTTP.
• Confirme que o seu consumidor é idempotente: todas as opções podem entregar duplicatas.
• Decida se você precisa de ordem e em que nível: global, por entidade ou nenhum.
• Compare o seu maior payload com o limite de tamanho e com os blocos de 64 KB.
• Revise o atraso máximo se você agenda jobs para o futuro.
• Configure retenção, DLQ e alertas pela idade da mensagem mais antiga.
• Calcule o custo com a sua taxa real de falhas, número de destinos e tamanho de lote.
• Some o que a fila não cobra: computação do consumidor, plano base e transferência.
• Confira as tarifas na página oficial do provedor antes de decidir.

O comparador de filas da Codifly resume esses números com as premissas usadas; ajuste o cenário com o seu volume e os seus retries antes de comparar.