Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame PCD avalia. Leia de cima a baixo ou pule para uma seção.
Microsserviços exigem comunicação síncrona de solicitação/resposta e assíncrona orientada a eventos.
Use gRPC ou HTTP para chamadas síncronas. Use Pub/Sub para eventos assíncronos e distribuição (fan-out).
Por quê: O Pub/Sub desacopla completamente os serviços para confiabilidade e escalabilidade independente. Chamadas diretas fornecem respostas síncronas de baixa latência.
Um serviço de computação sem estado (Cloud Run, Cloud Functions) precisa processar arquivos temporários.
Use Cloud Storage para todas as operações de I/O de arquivos temporários.
Por quê: O sistema de arquivos local de plataformas serverless é efêmero, em memória e não compartilhado. O Cloud Storage fornece armazenamento durável e escalável acessível por todas as instâncias.
Gerenciar configuração e segredos específicos do ambiente para cargas de trabalho do GKE seguindo os princípios dos 12 fatores.
Use K8s ConfigMaps para configurações não sensíveis. Use Secret Manager para valores sensíveis, acessados de forma segura via Workload Identity.
Por quê: Secret Manager é uma solução mais segura, gerenciada e auditável do que K8s Secrets. O Workload Identity evita o gerenciamento e a distribuição de chaves de contas de serviço.
A aplicação tem picos extremos de tráfego, mas longos períodos de inatividade onde o custo deve ser minimizado.
Use Cloud Run com `min-instances` definido como 0.
Por quê: O Cloud Run pode escalar até zero, eliminando todos os custos de computação durante períodos de inatividade. GKE e Compute Engine exigem nós/instâncias mínimos em execução.
Implementar retries, circuit breakers e mTLS consistentemente em microsserviços sem alterações no código da aplicação.
Implante uma service mesh (Anthos Service Mesh) no GKE.
Por quê: Uma service mesh injeta resiliência, segurança e observabilidade no nível da plataforma, mantendo o código da aplicação limpo e garantindo um comportamento consistente.
Expor serviços de backend para parceiros externos ou aplicações móveis com limitação de taxa, chaves de API e análise de uso.
Use API Gateway na frente de serviços de backend (por exemplo, Cloud Run, GKE).
Por quê: O API Gateway fornece uma solução totalmente gerenciada para questões do ciclo de vida da API (segurança, monitoramento, versionamento), desonerando-as do serviço de backend.
Selecionar um armazenamento durável, escalável e fortemente consistente para um log de eventos somente de adição (append-only).
Use Cloud Spanner para o armazenamento de eventos.
Por quê: O Spanner oferece escalabilidade horizontal com forte consistência global, crucial para manter a integridade de um log de eventos em escala.
Uma API para um trabalho de longa duração deve responder imediatamente enquanto o processamento continua em segundo plano.
O endpoint da API enfileira uma tarefa no Pub/Sub ou Cloud Tasks e retorna um 202 Accepted com um ID de trabalho. Um worker separado (Cloud Run, Cloud Function) processa a tarefa.
Por quê: Isso desacopla o tempo de resposta voltado para o usuário do tempo de processamento de backend, melhorando a UX e a confiabilidade do sistema. Use Cloud Storage para atualizações de status.
Manter a consistência dos dados em múltiplos microsserviços sem um banco de dados compartilhado.
Implemente o padrão Saga usando um orquestrador (Cloud Workflows) ou coreografia (eventos Pub/Sub) com transações de compensação.
Por quê: Evita commits de duas fases complexos e propensos a bloqueios, favorecendo a consistência eventual, que é mais adequada para sistemas distribuídos.
A aplicação chama uma API de terceiros com limitação de taxa onde os dados mudam com pouca frequência.
Use Memorystore for Redis como um cache distribuído. Implemente o padrão cache-aside com TTL. Use um bloqueio distribuído (por exemplo, Redis SETNX) para evitar "cache stampedes".
Por quê: Um cache distribuído compartilha dados entre todas as instâncias da aplicação, reduzindo drasticamente as chamadas para a API externa, melhorando a latência e respeitando os limites de taxa.
Uma equipe de desenvolvimento precisa de ambientes de desenvolvimento consistentes, pré-configurados e seguros, com acesso a recursos privados de VPC.
Use Cloud Workstations.
Por quê: O Cloud Workstations fornece ambientes de desenvolvimento gerenciados e baseados em contêineres, com segurança integrada e acesso à VPC, resolvendo o problema de "funciona na minha máquina".
Uma aplicação SaaS exige que os inquilinos tenham dados, chaves de criptografia e residência de dados completamente isolados.
Use um modelo de projeto por inquilino. Gerencie o provisionamento e a configuração centralmente usando IaC (Terraform).
Por quê: Oferece o mais alto nível de isolamento para IAM, faturamento, cotas, rede e localização de dados, muitas vezes exigido por clientes empresariais ou regulados.
Garantir que apenas imagens de contêiner confiáveis e escaneadas de um pipeline oficial possam ser implantadas em produção.
Use Cloud Build para gerar proveniência SLSA, Artifact Registry para varredura de vulnerabilidades e Binary Authorization para aplicar políticas de implantação baseadas em atestações.
Por quê: Cria uma cadeia criptográfica de confiança verificável e incontornável do código à implantação, impedindo a implantação de artefatos comprometidos ou não escaneados.
Implante uma nova versão de um serviço Cloud Run, teste-a sem impacto para o usuário e mude o tráfego instantaneamente.
Implante a nova revisão com `--no-traffic`. Teste usando a URL de revisão única ou uma tag de revisão. Mude 100% do tráfego para a nova revisão após a validação.
Por quê: O gerenciamento de tráfego nativo do Cloud Run permite implantações seguras e sem tempo de inatividade, validando a nova versão antes que ela receba qualquer tráfego de produção.
Distribuir gradualmente uma nova versão, analisando métricas automaticamente e revertendo em caso de falha.
Use Cloud Deploy com uma estratégia de implantação canary. Integre com Cloud Monitoring para análise automatizada de métricas e gatilhos de reversão.
Por quê: O Cloud Deploy automatiza todo o fluxo de trabalho de entrega progressiva, incluindo análise de métricas e verificações de segurança, reduzindo o esforço manual e o risco.
Gerenciar manifestos Kubernetes para ambientes de desenvolvimento, staging e produção sem duplicar código.
Use Kustomize ou Helm. Defina uma configuração base e crie overlays ou arquivos de valores específicos do ambiente para aplicar as diferenças.
Por quê: Segue o princípio DRY, tornando as configurações mais fáceis de gerenciar e reduzindo o risco de desvio de ambiente.
Reduzir o tamanho da imagem do contêiner para implantações mais rápidas e uma superfície de ataque menor.
Use builds multi-stage. Uma etapa de `build` usa uma imagem completa de SDK/JDK; a etapa final copia apenas o artefato compilado para uma imagem base `distroless` mínima.
Por quê: A imagem final contém apenas a aplicação e suas dependências de tempo de execução, removendo todas as ferramentas de build, shells e gerenciadores de pacotes.
Implantar ambientes efêmeros automaticamente para cada pull request para validação antes da fusão.
Use gatilhos do Cloud Build em eventos de PR para implantar no Cloud Run com uma tag de revisão (por exemplo, `pr-123`). Use outro gatilho no fechamento da PR para limpar a revisão marcada.
Por quê: As tags de revisão fornecem URLs únicas e temporárias para cada PR sem a sobrecarga de criar novos serviços, tornando-o econômico e fácil de automatizar.
Melhorar a velocidade e a confiabilidade do build de CI/CD armazenando em cache dependências de software públicas (por exemplo, de npm, Maven Central).
Use um repositório remoto do Artifact Registry, que atua como um cache pull-through para o repositório público.
Por quê: Melhora o desempenho do build, isola os builds de interrupções de registros públicos e permite a varredura de vulnerabilidades em artefatos em cache.
Armazenar e bloquear com segurança o estado do Terraform para execuções simultâneas de pipelines CI/CD.
Use um backend do Cloud Storage para o estado do Terraform, com IAM apropriado para a conta de serviço do Cloud Build.
Por quê: O Cloud Storage fornece um backend durável, versionado e bloqueável, prevenindo a corrupção de estado por builds concorrentes.
Um Cloud Run ou Cloud Function precisa acessar um recurso (por exemplo, Cloud SQL, Memorystore) em uma rede VPC privada.
Configure um conector de Acesso Serverless VPC.
Por quê: O conector atua como uma ponte de rede, permitindo o tráfego de saída do ambiente serverless para a VPC de destino sem expor recursos publicamente.
Uma aplicação stateful no GKE requer identidade estável e armazenamento persistente que sobreviva a falhas de pod/nó.
Use um StatefulSet com um Serviço Headless para identidade. Use um PersistentVolumeClaim (PVC) com um Persistent Disk regional para armazenamento.
Por quê: Este é o padrão canônico do Kubernetes para cargas de trabalho stateful, garantindo persistência de dados, alta disponibilidade e nomeação/rede de pods previsíveis.
Um pod no GKE precisa acessar APIs do GCP de forma segura sem gerenciar chaves estáticas de conta de serviço.
Configure e use Workload Identity.
Por quê: O Workload Identity vincula uma conta de serviço Kubernetes a uma conta de serviço Google, permitindo que os pods usem credenciais GCP de curta duração obtidas do servidor de metadados.
Executar um trabalho em lote que leva horas para ser concluído (por exemplo, processar um arquivo grande, agregação noturna de dados).
Use trabalhos do Cloud Run, acionados por Eventarc ou Cloud Scheduler.
Por quê: Os trabalhos do Cloud Run são projetados para tarefas de longa duração (até 24h), escalam para zero e são mais econômicos e simples do que um cluster GKE dedicado ou VM para cargas de trabalho em lote.
Implantar uma aplicação multi-contêiner no Cloud Run onde um contêiner principal precisa de um sidecar para logging, métricas ou como um proxy.
Implante o serviço Cloud Run com várias imagens de contêiner especificadas, uma como o contêiner principal e outras como sidecars.
Por quê: O suporte nativo a múltiplos contêineres do Cloud Run permite o padrão sidecar para cargas de trabalho serverless sem a complexidade do GKE.
As migrações de banco de dados devem ser concluídas antes que uma nova revisão do Cloud Run receba tráfego.
Execute migrações durante a inicialização do contêiner e use uma sonda de inicialização do Cloud Run que só passa depois que as migrações são bem-sucedidas.
Por quê: A sonda de inicialização atrasa o roteamento de tráfego até que o contêiner esteja totalmente pronto, garantindo que o esquema do banco de dados esteja correto antes que quaisquer solicitações sejam atendidas.
Uma aplicação GKE precisa escalar com base em uma métrica personalizada como a profundidade da fila do Pub/Sub, e não apenas CPU/memória.
Use o Horizontal Pod Autoscaler (HPA) configurado para ler métricas personalizadas do Cloud Monitoring.
Por quê: Isso permite que o autoescalonamento seja impulsionado pela lógica de negócios ou indicadores de carga específicos da aplicação, proporcionando um escalonamento mais preciso do que métricas de recursos genéricas.
Um serviço orientado a mensagens deve processar cada mensagem exatamente uma vez, apesar das retentativas e potenciais entregas duplicadas.
Combine Pub/Sub (com entrega "at-least-once" ou "exactly-once") com um consumidor idempotente. O consumidor rastreia os IDs das mensagens processadas em um armazenamento persistente (por exemplo, Firestore, Memorystore).
Por quê: O Pub/Sub garante a entrega, mas o consumidor é responsável pela idempotência para lidar com retentativas em nível de aplicação e alcançar um processamento verdadeiramente "exactly-once".
Eventos relacionados à mesma entidade (por exemplo, um usuário específico) devem ser processados na ordem em que foram gerados.
Publique mensagens no Pub/Sub com uma `orderingKey`. Habilite a ordenação de mensagens na assinatura.
Por quê: O Pub/Sub garante que as mensagens com a mesma chave de ordenação sejam entregues em ordem, enquanto as mensagens com chaves diferentes podem ser processadas em paralelo para escalabilidade.
Garantir que uma tarefa (por exemplo, gerar relatório diário de usuário) seja executada apenas uma vez, mesmo que múltiplos eventos de gatilho cheguem.
Use Cloud Tasks. Crie tarefas com nomes explícitos (por exemplo, `report-userX-2024-10-26`). O Cloud Tasks irá desduplicar requisições para criar uma tarefa com um nome existente.
Por quê: Isso transfere a lógica de desduplicação para o serviço de fila, simplificando o código da aplicação e prevenindo trabalho redundante.
Uma mensagem do Pub/Sub falha consistentemente no processamento após múltiplas retentativas e está bloqueando a fila.
Configure um tópico de dead-letter (DLQ) na assinatura do Pub/Sub e defina um número máximo de tentativas de entrega.
Por quê: O Pub/Sub move automaticamente a mensagem "venenosa" para a DLQ, permitindo que outras mensagens sejam processadas e preservando a mensagem falhada para análise.
Um processo de negócio envolve uma sequência de chamadas de serviço com lógica condicional, tratamento de erros e longas esperas.
Use Cloud Workflows para definir e executar a lógica de orquestração.
Por quê: O Cloud Workflows é um orquestrador serverless que gerencia estado, retentativas e longas esperas, proporcionando melhor confiabilidade e visibilidade do que funções encadeadas manualmente.
Um serviço Cloud Function ou Cloud Run deve ser acionado apenas por eventos de nuvem específicos (por exemplo, certos tipos de arquivo no Cloud Storage).
Use um gatilho Eventarc com filtragem CEL (Common Expression Language) em atributos de evento.
Por quê: A filtragem ocorre antes que o serviço seja invocado, economizando custos e ciclos de computação ao não processar eventos irrelevantes.
Limitar a taxa de chamadas de saída para uma API de terceiros de um serviço escalado horizontalmente como o Cloud Run.
Enfileirar chamadas de API como tarefas em uma fila do Cloud Tasks com `rateLimits` configurado (por exemplo, máximo de despachos por segundo).
Por quê: O Cloud Tasks fornece limitação de taxa centralizada e serverless que funciona em todas as instâncias escaladas sem a necessidade de contadores distribuídos complexos.
Autenticar chamadas de forma segura entre dois serviços Cloud Run (ou Cloud Functions).
Conceda à conta de serviço do serviço chamador a função IAM `roles/run.invoker` no serviço chamado. O chamador envia um token de ID assinado pelo Google com sua solicitação.
Por quê: Este é o método nativo, seguro e sem chaves para autenticação de serviço para serviço, aproveitando a infraestrutura de identidade do Google.
Um serviço orientado a eventos precisa reagir a alterações em nível de linha em um banco de dados Cloud SQL em tempo quase real.
Use Datastream (CDC) para transmitir alterações do banco de dados para o Pub/Sub. Use Eventarc para acionar um serviço Cloud Run a partir do tópico Pub/Sub.
Por quê: Este é um padrão desacoplado e confiável que evita o polling do banco de dados e não requer a modificação da aplicação que escreve no banco de dados.
Um processo de negócio de longa duração deve pausar para aguardar um evento externo, como um humano clicando em um link de aprovação em um e-mail.
Use Cloud Workflows com um endpoint de callback. O workflow pausa (por até um ano) até receber uma requisição HTTP em sua URL de callback única.
Por quê: Callbacks permitem que os workflows aguardem eventos externos sem consumir recursos de computação, tornando-o ideal para processos de longa duração com intervenção humana.
Uma aplicação serverless sensível à latência experimenta respostas iniciais lentas após períodos de inatividade.
Configure `min-instances` para 1 ou mais. Para "cold starts" inevitáveis, use `startup-cpu-boost`. Otimize também a aplicação (imagem menor, inicialização mais rápida).
Por quê: `min-instances` é a forma mais eficaz de eliminar "cold starts", mas incorre em custos. `startup-cpu-boost` acelera o próprio processo de inicialização.
Uma requisição está lenta ou falhando em múltiplos microsserviços, e o gargalo não é óbvio a partir de logs ou métricas de serviço individuais.
Use Cloud Trace com propagação de contexto. Instrumente as aplicações para encaminhar cabeçalhos de rastreamento (por exemplo, W3C Trace Context).
Por quê: O Cloud Trace fornece uma visualização em cascata de todo o ciclo de vida da requisição em todos os serviços, identificando a origem da latência ou dos erros.
Uma aplicação está lenta em produção, e não está claro se o problema é vinculado à CPU, um vazamento de memória ou I/O.
Use Cloud Profiler para analisar continuamente o uso de CPU e heap em produção.
Por quê: O Cloud Profiler identifica gargalos de desempenho em nível de código (hot paths, vazamentos de memória) com muito baixa sobrecarga, sem a necessidade de reproduzir problemas em um ambiente de teste.
Mudar de alertas simples de limite (por exemplo, "latência > 500ms") para alertas mais significativos baseados em Objetivos de Nível de Serviço (SLOs).
Defina SLIs e SLOs no Cloud Monitoring. Crie políticas de alerta baseadas na "taxa de consumo" do orçamento de erro.
Por quê: O alerta por taxa de consumo é mais sensível a mudanças significativas e menos ruidoso do que alertas simples de limite, sinalizando quando você está em uma trajetória para não cumprir seu SLO.
Agrupar exceções de aplicação de múltiplos serviços para rastrear a frequência, ver stack traces e ser notificado sobre novos tipos de erro.
Use Cloud Error Reporting.
Por quê: O Error Reporting ingere, agrupa e analisa automaticamente exceções de logs estruturados, fornecendo um painel centralizado para gerenciar erros de aplicação.
Monitorar, visualizar e alertar sobre métricas de negócios personalizadas (por exemplo, pedidos por minuto, novos registros de usuários).
Instrumente o código da aplicação usando o SDK OpenTelemetry. Configure o exportador para enviar métricas para o Cloud Monitoring.
Por quê: Este é o padrão moderno e agnóstico de fornecedor para instrumentação personalizada. Ele permite rastrear qualquer métrica e aproveitar todos os recursos do Cloud Monitoring para ela.