Hey pessoal, sou eu de novo. YEAHH!!!

A maioria dos desenvolvedores usa Pub/Sub do jeito errado, e depois culpa o Google quando as mensagens ficam reentregando pra sempre ou quando o Cloud Run acorda às 3 da manhã sem motivo.

Hoje eu vou mostrar o fluxo prático, o que realmente funciona em produção.

Então hoje vamos falar sobre GCP Pub/Sub integrado com GCP Cloud Run.

Vem comigo nessa jornada maravilhosa pelo Google Cloud Platform.

Este artigo é a primeira parte sobre Pub/Sub.

Na segunda parte, vamos fazer o caminho de volta. Você verá isso no próximo artigo.

Introdução

Você deve estar se perguntando: o que diabos é Pub/Sub?

Basicamente, vamos implementar este fluxo:

Backend → Pub/Sub Topic → Eventarc → Cloud Run → Pub/Sub Response → Backend

Pub/Sub é um serviço totalmente gerenciado de mensagens em tempo real que permite enviar e receber mensagens entre aplicações independentes.

Pub/Sub

• Publish → uma aplicação ou serviço envia uma mensagem para um tópico.
• Subscribe → outra aplicação ou serviço recebe essas mensagens assinando o tópico.

No meu caso, vou fazer assim:

1. Meu backend publica uma mensagem tipo “começar a processar o item X” em um tópico Pub/Sub.
2. O app serverless está inscrito nesse tópico, acorda automaticamente, processa a nota e publica outra mensagem tipo “item X finalizado” ou o resultado final.
3. Meu backend pode então receber essa resposta final ou checar o status do job.
4. 
   

Mas Anderson, me diz: como o Pub/Sub sabe que o backend processou?

Pull subscriptions

• O código precisa ack a mensagem.
• Se você der nack (ou deixar o deadline expirar), o Pub/Sub reentrega.
• Você também pode estender o ack deadline enquanto está trabalhando.
• 
  

Push subscriptions

• O endpoint responde com HTTP 2xx para confirmar o ack.
• Qualquer status diferente de 2xx dispara retry com backoff exponencial.
• 
  

Retries e Backoff

• A reentrega usa uma política de retry configurável (min/max backoff).
• Se nada for configurado, ele tenta novamente assim que o ack deadline expira ou no nack.
• Para push, o backoff é exponencial e gerenciado pelo Pub/Sub.

Dead-letter Handling

• Configure um Dead Letter Topic (DLT) com o número máximo de tentativas.
• Quando uma mensagem excede esse limite, o Pub/Sub envia ela para o DLT, onde você pode inspecionar ou reprocessar.
• Também é possível ler o campo deliveryAttempt.

Garantias de Entrega

• O padrão é at-least-once delivery, ou seja: o assinante pode receber duplicatas.
• Use o messageId (consistente em reentregas) ou seu próprio ID para deduplicar.
• Se você precisa de algo mais forte, ative Exactly-once delivery numa pull subscription.
• Você também recebe confirmação de que o ack foi de fato registrado.

Obs.: Exactly-once vale apenas para pull e depende da região.

Ordering (opcional, mas ótimo para EDA)

Para manter ordem por entidade (como por job_id), publique com uma ordering key e consuma na mesma região.

Atenção: quando uma mensagem com aquela key está sendo reentregada, mensagens posteriores da mesma key podem ser retidas para garantir a ordem.

O que é at-least-once?

Garante que cada mensagem será entregue uma ou mais vezes, mas nunca perdida.

Você pode receber duplicatas, mas nunca perde eventos, se o assinante for idempotente.

O que é exactly-once?

Cada mensagem é entregue e processada apenas uma vez para um assinante que reconhece com sucesso.

Vamos começar passo a passo

No futuro, posso mostrar como fazer isso com Terraform.

Quando falei sobre deploy de Cloud Run, também expliquei sobre IAM da GCP, então se quiser rever:

https://www.linkedin.com/pulse/automatic-deploy-google-cloud-run-using-artifact-registry-arruda-nqtpf/?trackingId=QKDhxKn0nose8J87iEHFTg%3D%3D

Se quiser saber mais sobre GCP IAM, aqui está:

https://cloud.google.com/iam/docs

No meu caso estou usando uma chave JSON com nível owner para criar os recursos de Pub/Sub, porque só eu tenho acesso ao projeto.

Mas em empresas, o ideal é sempre dar apenas as permissões necessárias.

Autenticando e Criando o Pub/Sub

Depois de autenticar com o gcloud-cli, liste os projetos e escolha o correto.

Listando projetos

gcloud projects list

Escolhendo o projeto

gcloud config set project <PROJECT_ID>

Criando um tópico Pub/Sub

gcloud pubsub topics create <TOPIC_ID>

Você verá uma mensagem dizendo que o tópico foi criado, algo como:

projects/<PROJECT_ID>/topics/<TOPIC_ID>

Criando subscriptions

gcloud pubsub subscriptions create <SUBSCRIPTION_ID> --topic=<TOPIC_ID>

Configurando o Cloud Run para ouvir o tópico

Listando serviços do Cloud Run

gcloud run services list

Várias regiões:

gcloud run services list --region=us-central1

Criando o Trigger do Eventarc (método recomendado)

gcloud eventarc triggers create <EVENTARC_NAME> \
 --destination-run-service=<SERVICE_NAME> \
 --destination-run-region=<REGION_ID> \
 --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished" \
 --transport-topic=<TOPIC_NAME> \
 --location=<REGION> \
 --service-account=<SERVICE_ACCOUNT>

Explicação dos parâmetros

• destination-run-service → serviço Cloud Run que será executado
• destination-run-region → região desse Cloud Run
• event-filters → tipo de evento Pub/Sub que queremos ouvir
• transport-topic → tópico Pub/Sub para o Eventarc ouvir
• location → região onde o trigger será criado
• service-account → conta usada pelo Eventarc para invocar o serviço

Crie uma service account apenas com as permissões necessárias.

Para o Eventarc, só precisamos da permissão de invocar o Cloud Run.

Publicando Mensagens no Pub/Sub via Laravel

Precisamos de outra service account para publicar mensagens.

O Eventarc vai receber a mensagem e acordar o Cloud Run para fazer o trabalho.

Crie uma service account e gere o JSON para usar no Laravel.

Essa conta precisa apenas do:

• roles/pubsub.publisher

Em português o nome parece estranho (“Editor de Pub/Sub”), mas a descrição confirma que ela só publica, então está certo.

Instale o Pub/Sub no Laravel

composer require google/cloud-pubsub

E aqui está o Job:

// código mantido como no original

Imagine uma empresa processando milhares de notas por dia. Normalmente ela precisaria de:

• um servidor rodando 24/7
• retries manuais
• uma equipe monitorando jobs travados
• infraestrutura enorme só pra picos
• desenvolvedores cuidando de processos longos

Com Pub/Sub + Eventarc + Cloud Run, tudo muda:

• nada roda sem necessidade
• falhas recuperam sozinhas
• duplicatas são tratadas de forma idempotente
• a ordem por cliente ou nota é preservada
• o paralelismo cresce automaticamente
• a empresa paga só pelos segundos de execução real

Um processo que antes custava entre R$ 400 700/mês em uma VM cai para R$ 20 a 60/mês.

O impacto de negócio é enorme:

• escala automática
• operações previsíveis
• menos incidentes
• entregas mais rápidas
• custo total reduzido
• alta disponibilidade “de graça”

Esse tipo de arquitetura transforma empresas, não por hype, mas porque elimina desperdício e devolve produtividade para o time.

Depois de tudo isso, você já consegue testar o sistema.

Isso vai publicar no tópico, mas não vai consumir, porque o Laravel só publica, não assina.

Você pode controlar tudo usando messageIds.

No meu caso, o resultado do crawler fica atrelado ao ID da mensagem.

Pub/Sub é muito mais que uma fila, é o coração de uma arquitetura event-driven moderna na GCP.

Com a configuração certa, você ganha retries previsíveis, autoscaling, garantias de entrega e um desacoplamento limpo entre os sistemas.

Nesta primeira parte, vimos a publicação via Laravel e o trigger do Cloud Run usando Eventarc.

Na próxima, vamos fechar o ciclo: Cloud Run → Pub/Sub → Backend.

Se quiser a segunda parte, comenta aí ou me manda uma mensagem e eu publico.

Vejo vocês no próximo!