Na etapa anterior, preparamos uma conta IAM que permite que uma aplicação publique em um tópico. Agora avançamos para o outro lado da equação: receber as informações que voltam do Google Cloud Run. Este é um daqueles momentos em que a infraestrutura deixa de ser apenas um conjunto de comandos e começa a se transformar em um sistema que trabalha a seu favor.

Começamos criando um novo tópico. Primeiro, verifique o ID do seu projeto:

gcloud projects list

Depois crie o tópico:

gcloud pubsub topics create {{TOPIC_NAME}} --project={{PROJECT_ID}}

Onde

• {{TOPIC_NAME}} é o nome do seu tópico
• {{PROJECT_ID}} é o ID do seu projeto

Com o tópico pronto, criamos a push subscription. É ela a responsável por entregar as mensagens automaticamente ao seu backend, com tentativas de reenvio e sem depender da estabilidade de uma única chamada HTTP.

gcloud pubsub subscriptions create {{PUSH_NAME}} \
  --topic={{TOPIC_NAME}} \
  --push-endpoint={{ENDPOINT}} \
  --push-auth-service-account={{IAM_ACCOUNT}} \
  --ack-deadline=600 \
  --message-retention-duration=3d

Onde:

• {{PUSH_NAME}} é o nome da assinatura
• {{TOPIC_NAME}} é o tópico criado no passo anterior
• {{ENDPOINT}} é o endpoint do backend que recebe o webhook
• {{IAM_ACCOUNT}} é a conta de serviço usada para autenticação

Explicações

• topic é o tópico que a push subscription escuta
• push-endpoint é o endpoint que recebe o webhook
• push-auth-service-account é a conta usada para autenticar
• ack-deadline é o tempo que o Pub Sub espera antes de tentar novamente
• message-retention-duration define por quanto tempo mensagens não entregues ficam armazenadas

Depois disso configurado, o seu backend só precisa de um endpoint que retorne qualquer status 2xx. Se o endpoint responder fora do intervalo 2xx, o Pub Sub cuida das novas tentativas automaticamente até o final do período de retenção.

Neste ponto tudo funciona, mas entender por que usamos essa abordagem é o que separa alguém que apenas conhece comandos de alguém que projeta sistemas que realmente escalam.

Ao usar Pub Sub Push em vez de chamar o backend diretamente, você ganha confiabilidade. O Pub Sub foi criado com uma estratégia de retry que protege sua pipeline contra redes instáveis, lentidão ou falhas momentâneas. Em vez de carregar essa responsabilidade dentro do seu código, você entrega para um serviço totalmente gerenciado e projetado exatamente para isso. O resultado é menos perda de eventos e muito menos esforço operacional.

Um webhook direto vindo do Cloud Run é simples, mas não possui tentativas automáticas de reenvio. Você teria que implementar sua própria política de retries, persistência de falhas, backoff exponencial e mecanismos para evitar sobrecarga. Construir tudo isso manualmente não faz sentido no cenário atual, quando o Pub Sub já resolve de forma mais robusta e com menor custo.

Essa arquitetura também ajuda a economizar dinheiro. O Cloud Run oferece um milhão de requisições gratuitas por mês. Quando o Pub Sub atua como buffer, o sistema evita chamadas desnecessárias e distribui a carga de forma muito mais eficiente. O resultado é uma estrutura que não apenas funciona hoje, mas que está pronta para crescer sem reescritas dolorosas ou explosões de custo.

São exatamente esses tipos de decisões de arquitetura que chamam a atenção de CTOs e CEOs. Elas mostram que o sistema é resiliente, o custo é previsível e a plataforma está preparada para crescer. Recrutadores prestam atenção nisso também. Demonstra domínio de sistemas distribuídos, padrões orientados a eventos, autenticação entre serviços internos e decisões conscientes de custo que fazem sentido em produção.

No próximo artigo, vamos automatizar tudo isso usando Terraform. Quando sua infraestrutura vira código, criar um novo ambiente deixa de ser uma checklist manual e passa a ser um único comando. Esse ganho de tempo representa eficiência operacional e também maturidade na forma como você projeta e escala sistemas.

No fim, esta é a diferença entre simplesmente fazer deploy de código e criar sistemas que as pessoas podem confiar sem hesitação. Eu construo arquiteturas que não dependem de sorte, não quebram sob pressão e não precisam de desculpas. Elas funcionam porque cada decisão é intencional, cada detalhe é compreendido e cada parte da estrutura foi criada para escalar. Quando você opera neste nível, confiança não é postura, é consequência natural de saber exatamente o que está fazendo.

Se quiser, posso formatar essa versão em HTML, Markdown para blog, ou transformar em um carrossel para LinkedIn.