Google PCD: Design de API, Integração e Desenvolvimento Orientado a Eventos — Guia de estudos

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Faz parte do Google Professional Cloud Developer — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A integração de aplicações modernas no Google Cloud combina APIs síncronas bem projetadas com padrões assíncronos e orientados a eventos resilientes. O objetivo é fornecer contratos claros, identidade forte, tratamento de erros consistente e controles operacionais que mantêm a latência baixa e a disponibilidade alta mesmo sob falhas, escalonamento ou mudanças. Esta seção aborda escolhas de protocolo e API, gateways e autenticação, mensageria e roteamento de eventos, trabalho em segundo plano (background), orquestração, identidade e confiança entre serviços, padrões de confiabilidade, webhooks seguros e evolução segura de esquemas (schemas).

Design e Gerenciamento de APIs

Escolha o protocolo certo:

REST: Amigável para humanos, cacheável via HTTP, ótimo para APIs públicas e de parceiros. Use um design orientado a recursos, métodos padrão, ETags e HATEOAS apenas quando for valioso. Desvantagem: contratos menos precisos que o protobuf; potencial de over-fetching (busca de dados em excesso) ou under-fetching (busca de dados insuficientes).
gRPC: Contratos Protobuf, streaming bidirecional, transporte binário eficiente; ideal para chamadas internas de serviço a serviço de baixa latência. Desvantagem: o suporte em navegadores requer gRPC-Web; a observabilidade e a compatibilidade para clientes públicos podem ser mais difíceis.
GraphQL: Consultas flexíveis que reduzem as viagens de ida e volta (round-trips) para visualizações compostas. Desvantagem: resolvers complexos, riscos de N+1, desafios de cache e nuances no controle de acesso.

Versionamento e paginação:

Prefira mudanças aditivas e retrocompatíveis. Use versões maiores (major versions) baseadas em URI (ex: /v1) e revisões menores (minor revisions) por meio de campos e feature flags. Deprecie com cronogramas claros.
Pagine com cursores estáveis ou nextPageToken para evitar páginas inconsistentes sob alta rotatividade (churn); evite o uso de offset para grandes conjuntos de dados.

Validação e erros:

Use OpenAPI para esquemas (schemas) de requisição/resposta REST e regras de validação do protobuf para gRPC.
Adote um modelo de erro consistente: mapeie para códigos de status HTTP canônicos; para gRPC, use google.rpc.Status (código, mensagem, detalhes). Inclua motivos de erro que possam ser analisados por máquinas (machine-parsable) e um ID de correlação. Evite vazar detalhes internos.

Opções de gerenciamento de API:

API Gateway: Gateway gerenciado e leve para backends OpenAPI/gRPC (Cloud Run, Cloud Functions, GKE, Compute Engine). Suporta autenticação, chaves de API, validação de JWT, cotas. Bom para serverless e planos de controle diretos.
Cloud Endpoints (ESPv2): Implantado junto com seu serviço; suporta transcodificação OpenAPI ou gRPC, autenticação, cotas e métricas. Bom para quando é preferível colocalizar o proxy com a carga de trabalho (workload).
Apigee: Gerenciamento completo do ciclo de vida da API com políticas avançadas (spike arrest, cotas, mediação, transformação, provedores OAuth, monetização, portal do desenvolvedor). Melhor para ecossistemas de parceiros complexos e controle norte-sul.

Autenticação e cotas:

Para usuários finais: OAuth 2.0 ou Firebase Authentication; para serviços: ID tokens assinados pelo Google (OIDC) ou tokens de conta de serviço OAuth (2-legged).
Aplique cotas e spike arrest perto dos clientes (Apigee) e por consumidor (chaves de API ou credenciais de cliente) para proteger os backends.

Exemplo mínimo de OpenAPI para o API Gateway com backend no Cloud Run e OIDC:

openapi: 3.0.0
info: {title: orders, version: 1.0.0}
paths:
  /v1/orders:
    get:
      security: [{firebase: []}]
      x-google-backend: {address: https://orders-xyz-uc.a.run.app}
      responses: {"200": {description: OK}}
components:
  securitySchemes:
    firebase:
      type: http
      scheme: bearer
      bearerFormat: JWT
      x-google-issuer: https://securetoken.google.com/PROJECT_ID
      x-google-audiences: PROJECT_ID

Mensageria Assíncrona e Eventos

Fundamentos do Pub/Sub:

Tópicos e inscrições (subscriptions) desacoplam publicadores (publishers) e consumidores (consumers). A entrega é do tipo “pelo menos uma vez” (at-least-once); duplicatas e reordenação podem ocorrer.
Use confirmações (acknowledgments) e estenda os prazos de confirmação (ack deadlines) quando o processamento for longo; aplique controle de fluxo no cliente para evitar pressão na memória.
Ordenação: habilite a ordenação de mensagens e forneça uma chave de ordenação (ordering key) para garantir a entrega em ordem por chave; mantenha um único publicador ativo por chave, quando possível.
Dead letters: configure tópicos de mensagens mortas (dead-letter topics) para conter “mensagens venenosas” (poison messages) e evitar novas tentativas infinitas; monitore e faça a triagem.

Crie um tópico, uma inscrição (subscription) e uma DLQ:

gcloud pubsub topics create orders
gcloud pubsub topics create orders-dlq
gcloud pubsub subscriptions create orders-sub \
  --topic=orders \
  --dead-letter-topic=orders-dlq \
  --max-delivery-attempts=5 \
  --ack-deadline=30

Lógica do consumidor: implemente handlers idempotentes e desduplicação (ex: por messageId ou chave de idempotência no nível da aplicação); tente novamente erros transitórios com backoff; mova mensagens irrecuperáveis para a DLQ e alerte.

Eventarc e CloudEvents:

O Eventarc roteia eventos de serviços do Google Cloud, fontes personalizadas e Audit Logs para o Cloud Run, Cloud Functions ou GKE. Os eventos usam o envelope CloudEvents (id, source, type, subject, time).
Filtre por atributos (type, subject, location) no gatilho (trigger) para reduzir o ruído e o custo. Use contas de serviço dedicadas para o princípio do menor privilégio.

Crie um gatilho (trigger) do Eventarc para a finalização de objetos no Cloud Storage:

gcloud eventarc triggers create index-new-objects \
  --destination-run-service=media-indexer \
  --destination-run-region=us-central1 \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=my-assets-bucket" \
  --service-account=eventarc-router@PROJECT_ID.iam.gserviceaccount.com

Desvantagens e Vantagens (Trade-offs):

O Pub/Sub é otimizado para pull e resiliente para alta vazão (throughput); o Eventarc simplifica o roteamento de produtores que você não controla e usa push para o seu serviço com metadados padronizados.
Para ordenação estrita ou limites rígidos de custo, considere particionamento e limitação de taxa (rate-limiting) nos publicadores; para fan-out de latência muito baixa, ajuste a concorrência dos assinantes (subscribers) com cuidado.

Orquestração, Trabalho em Segundo Plano e Processos de Longa Duração

Cloud Tasks:

Filas de push (push-queues) para chamadas HTTP em segundo plano (background) confiáveis. Defina a taxa de despacho e a concorrência por fila para proteger os backends. Configure novas tentativas (retries) com backoff exponencial e um número máximo de tentativas.
Garanta a idempotência com um nome de tarefa determinístico ou um cabeçalho Idempotency-Key e faça a desduplicação no lado do servidor. Responda rapidamente (2xx) e execute o trabalho pesado de forma assíncrona, se necessário.

Crie uma fila com limites de taxa e novas tentativas:

gcloud tasks queues create payments-queue \
  --max-dispatches-per-second=50 \
  --max-concurrent-dispatches=200 \
  --max-attempts=10 \
  --min-backoff=5s \
  --max-backoff=300s

Workflows:

Orquestra processos de negócios de várias etapas através de conectores HTTP e do Google Cloud. Modele ações de compensação (padrão saga) para falhas parciais; evite transações distribuídas.
Use timeouts no nível da etapa e políticas de nova tentativa; persista o estado entre as tentativas para que você possa continuar após interrupções. Faça polling de operações de longa duração e cancele-as no prazo final (deadline).

Esboço de compensação:

main:
  params: [orderId]
  steps:
  - charge:
      call: http.post
      args: {url: ${paymentsUrl}/charge, auth: {type: OIDC}, body: {orderId: ${orderId}}}
      result: chargeRes
  - reserveInventory:
      try:
        steps:
        - reserve:
            call: http.post
            args: {url: ${inventoryUrl}/reserve, auth: {type: OIDC}, body: {orderId: ${orderId}}}
      except:
        as: e
        steps:
        - refund:
            call: http.post
            args: {url: ${paymentsUrl}/refund, auth: {type: OIDC}, body: {paymentId: ${chargeRes.body.id}}}
        - raise: ${e}

Orientação operacional:

Prefira o Cloud Tasks para chamadas HTTP em segundo plano do tipo “fire-and-forget” com controle preciso de taxa para um único serviço. Use o Pub/Sub para fan-out e múltiplos consumidores. Use o Workflows quando precisar coordenar várias chamadas com lógica de ramificação (branching) e compensação.

Identidade, Confiabilidade e Integrações

Identidade de serviço para serviço e propagação de tokens:

Workloads do Cloud Run/Functions/Compute Engine/GKE devem usar contas de serviço com o menor privilégio. No GKE, use o Workload Identity para evitar credenciais no nível do nó.
Para chamadas de Cloud Run para Cloud Run, use um token de ID cuja audience corresponda à URL de destino. Propague a identidade somente quando o serviço downstream precisar agir em nome do chamador; caso contrário, use a conta de serviço do serviço chamado (callee).

Obtenha um token de ID no Cloud Run:

AUD="https://inventory-xyz-uc.a.run.app"
TOKEN=$(curl -s -H "Metadata-Flavor: Google" \
  "http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=${AUD}")
curl -H "Authorization: Bearer ${TOKEN}" "${AUD}/v1/check"

Dependências síncronas e resiliência:

Defina timeouts do cliente mais baixos que os timeouts do upstream; estabeleça um orçamento por salto (hop). Tente novamente apenas operações idempotentes com backoff exponencial truncado e jitter. Evite tempestades de retentativas (retry storms) limitando o tempo total de retentativa.
Use circuit breakers para falhar rapidamente (fail fast) quando um upstream não estiver saudável; no GKE/Apigee/Envoy, você pode configurar o máximo de requisições pendentes, ejeção em caso de falha e sondas de saúde (health probes). Forneça fallbacks sensatos ou degrade graciosamente.
Mapeie erros transitórios (429, 408, 500–503) para um comportamento de retentativa; trate os erros 4xx (exceto 408/429) como não repetíveis.

Webhooks e integrações de terceiros:

Verifique as requisições de entrada usando um cabeçalho de assinatura HMAC com um segredo compartilhado ou um JWT assinado; para maior garantia, use mTLS. Armazene os segredos no Secret Manager e rotacione-os regularmente.
Confirme o recebimento (acknowledge) rapidamente; enfileire no Cloud Tasks ou publique no Pub/Sub para desacoplar o processamento pesado. Aplique limites de taxa (rate-limit) a IPs ou chaves de entrada para proteger os backends.
Webhooks de saída: inclua uma Idempotency-Key para permitir retentativas seguras e verifique os certificados TLS e hostnames remotos.

Evolução de esquema e compatibilidade:

REST/JSON: campos aditivos são seguros; nunca reutilize ou altere o tipo/significado de campos existentes. Marque os campos como obsoletos (deprecated) e continue a servi-los por um período.
Protobuf/gRPC: nunca reutilize os números dos campos; use tags reservadas; prefira campos opcionais; a semântica de valores padrão (defaulting) e de presença é importante para a compatibilidade.
Eventos: inclua uma dataVersion e mantenha os atributos do CloudEvents estáveis; reserve espaço para extensões. Com o Pub/Sub, considere usar o Pub/Sub Schema (Avro/Protobuf) para validar no momento da publicação.
Testes: use testes de contrato orientados ao consumidor (consumer-driven contract tests), emuladores (Pub/Sub, Datastore/Firestore) ou projetos isolados e lançamentos canário (canary releases). Execute testes de integração em CI usando ambientes efêmeros e cotas realistas para expor falhas latentes.

Segurança e cotas em toda a stack:

Aplique autenticação na borda (API Gateway/Apigee/Endpoints) e no serviço. Aplique cotas por consumidor e contenção de picos (spike arrest).
Monitore picos de 401/403 e taxas de 429 para ajustar o backoff do cliente e as cotas.
Registre os IDs das requisições entre os componentes e propague os cabeçalhos de rastreamento (Traceparent ou X-Cloud-Trace-Context) para observabilidade de ponta a ponta.

Cenário de Problema Prático

A AcmeRetail está construindo um serviço de “clique e retire” (click-to-collect) no Google Cloud. Uma aplicação web em React chama uma API pública para fazer pedidos; os serviços de backend devem reservar o estoque, cobrar pagamentos e notificar as lojas. A equipe precisa de APIs de baixa latência, processamento em segundo plano confiável, atualizações orientadas a eventos e rollback seguro em caso de falhas parciais.

Abordagem:

Expor uma API REST pública via API Gateway na frente de um serviço de pedidos (orders) no Cloud Run.

Justificativa: REST com JSON é simples para navegadores; o API Gateway valida JWTs do Firebase Auth, impõe chaves de API e cotas por cliente e faz a terminação na borda. O Cloud Run escalona automaticamente com picos de tráfego.

Implementar chamadas de serviço para serviço com gRPC para os caminhos críticos internos (hot paths) (pedidos para estoque, precificação).

Justificativa: gRPC reduz a sobrecarga de serialização e fornece contratos rígidos. Usar Workload Identity (GKE) ou contas de serviço (Cloud Run) e OIDC entre os serviços. Os timeouts são definidos em 300 ms com duas retentativas e jitter para leituras idempotentes.

Usar o Workflows para orquestrar a saga do pedido: cobrar pagamento, reservar estoque, criar tarefa de retirada; compensar em caso de falha.

Justificativa: A orquestração centralizada gerencia etapas de longa duração e compensações. Se a reserva falhar, o Workflows aciona um reembolso e retorna um 409 para o cliente.

Publicar eventos de domínio nos tópicos orders e inventory do Pub/Sub para consumidores downstream (analytics, notificações de loja).

Justificativa: Distribuição em fan-out sem acoplamento forte. Os assinantes (subscribers) implementam idempotência com chave no orderId. As inscrições (subscriptions) têm tópicos de mensagens mortas (dead-letter topics) com max-delivery-attempts=10, e alertas são disparados com o crescimento da DLQ.

Disparar notificações para as lojas via Eventarc para um serviço notificador no Cloud Run em resposta a alterações relevantes no Cloud Storage e Firestore.

Justificativa: O Eventarc roteia apenas os eventos necessários usando filtros de atributo; o CloudEvents garante metadados consistentes. O notificador posta para provedores de SMS/E-mail de terceiros usando o Cloud Tasks para controlar a taxa e as retentativas.

Lidar com webhooks do provedor de pagamento com um endpoint dedicado no Cloud Run, protegido pelo API Gateway, verificando assinaturas HMAC e usando o Cloud Tasks para o processamento.

Justificativa: Um “ack” 200 rápido reduz as retentativas do provedor; o Tasks garante retentativas com backoff. Os segredos são armazenados no Secret Manager; os corpos das requisições são validados em relação ao esquema OpenAPI.

Aplicar padrões de confiabilidade: circuit breakers no Apigee ou Envoy para chamadas de saída para o provedor de pagamento; timeouts do cliente definidos abaixo dos SLAs do provedor; retentativas com backoff exponencial truncado para erros 429/5xx.

Justificativa: Previne falhas em cascata e tempestades de retentativas, respeita os limites de terceiros e transforma sobrecarga transitória em degradação graciosa.

Adotar controles de evolução de esquema: Protobuf para gRPC interno com campos reservados; respostas REST usam alterações JSON aditivas; o Pub/Sub usa validação de esquema Protobuf no momento da publicação.

Justificativa: Mantém a compatibilidade do consumidor. Testes de contrato e de integração são executados no Cloud Build a cada merge; implantações canário (canary deploys) validam o tráfego real com segurança.

Observar e operar: propagar cabeçalhos de rastreamento entre o API Gateway e os serviços; exportar métricas do Cloud Logging para taxas de erro e tamanho da DLQ; alertar sobre o consumo do SLO (burn) e anomalias de 429/5xx.

Justificativa: Detecção rápida de regressões, problemas de cota ou incidentes com provedores; os SREs podem ajustar cotas e políticas de backoff rapidamente.

← Computação · Todos os domínios · Dados de Aplicação →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →