Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen PCD. Lee de arriba a abajo o salta a una sección.
Los microservicios requieren comunicación síncrona de solicitud/respuesta y comunicación asíncrona basada en eventos.
Utilice gRPC o HTTP para llamadas síncronas. Utilice Pub/Sub para eventos asíncronos y distribución (fan-out).
Por qué: Pub/Sub desacopla completamente los servicios para fiabilidad y escalado independiente. Las llamadas directas proporcionan respuestas síncronas de baja latencia.
Un servicio de cómputo sin estado (Cloud Run, Cloud Functions) necesita procesar archivos temporales.
Utilice Cloud Storage para todas las operaciones de E/S de archivos temporales.
Por qué: El sistema de archivos local de las plataformas sin servidor es efímero, en memoria y no compartido. Cloud Storage proporciona almacenamiento duradero y escalable accesible por todas las instancias.
Gestione la configuración específica del entorno y los secretos para las cargas de trabajo de GKE siguiendo los principios de las 12-factor apps.
Utilice ConfigMaps de K8s para configuraciones no sensibles. Utilice Secret Manager para valores sensibles, accedidos de forma segura a través de Workload Identity.
Por qué: Secret Manager es una solución más segura, gestionada y auditable que los Secretos de K8s. Workload Identity evita la gestión y distribución de claves de cuentas de servicio.
La aplicación tiene picos de tráfico extremos pero largos periodos de inactividad donde el costo debe minimizarse.
Utilice Cloud Run con `min-instances` configurado a 0.
Por qué: Cloud Run puede escalar a cero, eliminando todos los costos de cómputo durante los periodos de inactividad. GKE y Compute Engine requieren nodos/instancias mínimos en ejecución.
Implemente reintentos, disyuntores y mTLS de manera consistente en microservicios sin cambios en el código de la aplicación.
Implemente una malla de servicios (Anthos Service Mesh) en GKE.
Por qué: Una malla de servicios inyecta resiliencia, seguridad y observabilidad a nivel de plataforma, manteniendo el código de la aplicación limpio y asegurando un comportamiento consistente.
Exponga servicios de backend a socios externos o aplicaciones móviles con limitación de velocidad, claves de API y análisis de uso.
Utilice API Gateway delante de los servicios de backend (por ejemplo, Cloud Run, GKE).
Por qué: API Gateway proporciona una solución totalmente gestionada para las preocupaciones del ciclo de vida de la API (seguridad, monitoreo, versionado), descargándolas del servicio de backend.
Seleccione un almacenamiento duradero, escalable y fuertemente consistente para un registro de eventos de solo anexión.
Utilice Cloud Spanner para el almacén de eventos.
Por qué: Spanner proporciona escalabilidad horizontal con una fuerte consistencia global, crucial para mantener la integridad de un registro de eventos a escala.
Una API para un trabajo de larga duración debe responder inmediatamente mientras el procesamiento continúa en segundo plano.
El endpoint de la API pone en cola una tarea en Pub/Sub o Cloud Tasks y devuelve un 202 Accepted con un ID de trabajo. Un worker separado (Cloud Run, Cloud Function) procesa la tarea.
Por qué: Esto desacopla el tiempo de respuesta al usuario del tiempo de procesamiento del backend, mejorando la UX y la fiabilidad del sistema. Utilice Cloud Storage para las actualizaciones de estado.
Mantener la consistencia de los datos en múltiples microservicios sin una base de datos compartida.
Implemente el patrón Saga utilizando un orquestador (Cloud Workflows) o coreografía (eventos de Pub/Sub) con transacciones de compensación.
Por qué: Evita commits de dos fases complejos y propensos a bloqueos, favoreciendo la consistencia eventual que es más adecuada para sistemas distribuidos.
La aplicación realiza llamadas a una API de terceros con limitación de velocidad donde los datos cambian con poca frecuencia.
Utilice Memorystore para Redis como una caché distribuida. Implemente el patrón cache-aside con TTL. Utilice un bloqueo distribuido (por ejemplo, Redis SETNX) para evitar avalanchas de caché.
Por qué: Una caché distribuida comparte datos entre todas las instancias de la aplicación, reduciendo drásticamente las llamadas a la API externa, mejorando la latencia y respetando los límites de velocidad.
Un equipo de desarrollo necesita entornos de desarrollo consistentes, preconfigurados y seguros con acceso a recursos privados de VPC.
Utilice Cloud Workstations.
Por qué: Cloud Workstations proporciona entornos de desarrollo gestionados, basados en contenedores, con seguridad integrada y acceso a VPC, resolviendo el problema de "funciona en mi máquina".
Una aplicación SaaS requiere que los tenants tengan datos, claves de cifrado y residencia de datos completamente aislados.
Utilice un modelo de proyecto por tenant. Gestione el aprovisionamiento y la configuración de forma centralizada utilizando IaC (Terraform).
Por qué: Proporciona el nivel más alto de aislamiento para IAM, facturación, cuotas, redes y ubicación de datos, a menudo requerido por clientes empresariales o regulados.
Asegurar que solo imágenes de contenedor confiables y escaneadas de una canalización oficial puedan implementarse en producción.
Utilice Cloud Build para generar la procedencia SLSA, Artifact Registry para el escaneo de vulnerabilidades y Binary Authorization para aplicar políticas de implementación basadas en atestaciones.
Por qué: Crea una cadena de confianza criptográfica verificable e ineludible desde el código hasta la implementación, previniendo la implementación de artefactos comprometidos o no escaneados.
Implementar una nueva versión de un servicio de Cloud Run, probarla sin impacto en el usuario y cambiar el tráfico instantáneamente.
Implemente la nueva revisión con `--no-traffic`. Pruebe usando la URL de revisión única o una etiqueta de revisión. Cambie el 100% del tráfico a la nueva revisión una vez validada.
Por qué: La gestión de tráfico nativa de Cloud Run permite implementaciones seguras y sin tiempo de inactividad al validar la nueva versión antes de que reciba tráfico de producción.
Desplegar gradualmente una nueva versión, analizando automáticamente métricas y revirtiendo en caso de fallo.
Utilice Cloud Deploy con una estrategia de despliegue canary. Integre con Cloud Monitoring para el análisis automatizado de métricas y los disparadores de reversión.
Por qué: Cloud Deploy automatiza todo el flujo de trabajo de entrega progresiva, incluido el análisis de métricas y las comprobaciones de seguridad, reduciendo el esfuerzo manual y el riesgo.
Gestionar manifiestos de Kubernetes para entornos de desarrollo, staging y producción sin duplicar código.
Utilice Kustomize o Helm. Defina una configuración base y cree superposiciones o archivos de valores específicos del entorno para aplicar las diferencias.
Por qué: Sigue el principio DRY, facilitando la gestión de configuraciones y reduciendo el riesgo de desajuste ambiental.
Reducir el tamaño de la imagen del contenedor para implementaciones más rápidas y una superficie de ataque más pequeña.
Utilice compilaciones multi-etapa. Una etapa de `build` utiliza una imagen completa de SDK/JDK; la etapa final copia solo el artefacto compilado en una imagen base `distroless` mínima.
Por qué: La imagen final contiene solo la aplicación y sus dependencias en tiempo de ejecución, eliminando todas las herramientas de compilación, shells y gestores de paquetes.
Implementar automáticamente entornos efímeros para cada pull request para validación antes de fusionar.
Utilice disparadores de Cloud Build en eventos de PR para implementar en Cloud Run con una etiqueta de revisión (por ejemplo, `pr-123`). Utilice otro disparador al cerrar el PR para limpiar la revisión etiquetada.
Por qué: Las etiquetas de revisión proporcionan URLs únicas y temporales para cada PR sin la sobrecarga de crear nuevos servicios, lo que lo hace rentable y fácil de automatizar.
Mejorar la velocidad y fiabilidad de las compilaciones CI/CD almacenando en caché las dependencias de software públicas (por ejemplo, de npm, Maven Central).
Utilice un repositorio remoto de Artifact Registry, que actúa como una caché de extracción (pull-through cache) para el repositorio público.
Por qué: Mejora el rendimiento de la compilación, aísla las compilaciones de interrupciones del registro público y permite el escaneo de vulnerabilidades en los artefactos en caché.
Almacenar y bloquear de forma segura el estado de Terraform para ejecuciones concurrentes de pipelines CI/CD.
Utilice un backend de Cloud Storage para el estado de Terraform, con el IAM adecuado para la cuenta de servicio de Cloud Build.
Por qué: Cloud Storage proporciona un backend duradero, versionado y bloqueable, previniendo la corrupción del estado por compilaciones concurrentes.
Un servicio de Cloud Run o Cloud Function necesita acceder a un recurso (por ejemplo, Cloud SQL, Memorystore) en una red VPC privada.
Configure un conector de acceso sin servidor a la VPC (Serverless VPC Access).
Por qué: El conector actúa como un puente de red, permitiendo el tráfico de salida desde el entorno sin servidor hacia la VPC de destino sin exponer recursos públicamente.
Una aplicación con estado en GKE requiere identidad estable y almacenamiento persistente que sobreviva a fallos de pod/nodo.
Utilice un StatefulSet con un Headless Service para la identidad. Utilice un PersistentVolumeClaim (PVC) con un Persistent Disk regional para el almacenamiento.
Por qué: Este es el patrón canónico de Kubernetes para cargas de trabajo con estado, asegurando la persistencia de datos, alta disponibilidad y nombres/redes de pod predecibles.
Un pod en GKE necesita acceder a las APIs de GCP de forma segura sin gestionar claves de cuentas de servicio estáticas.
Configure y utilice Workload Identity.
Por qué: Workload Identity vincula una cuenta de servicio de Kubernetes a una cuenta de servicio de Google, permitiendo a los pods utilizar credenciales de GCP de corta duración obtenidas del servidor de metadatos.
Ejecutar un trabajo por lotes que tarda horas en completarse (por ejemplo, procesar un archivo grande, agregación de datos nocturna).
Utilice trabajos de Cloud Run, activados por Eventarc o Cloud Scheduler.
Por qué: Los trabajos de Cloud Run están diseñados para tareas de larga duración (hasta 24h), escalan a cero y son más rentables y sencillos que un clúster GKE o una VM dedicada para cargas de trabajo por lotes.
Implementar una aplicación multi-contenedor en Cloud Run donde un contenedor principal necesita un sidecar para registro, métricas o como proxy.
Implemente el servicio de Cloud Run con múltiples imágenes de contenedor especificadas, una como contenedor principal y otras como sidecars.
Por qué: El soporte nativo de múltiples contenedores de Cloud Run habilita el patrón sidecar para cargas de trabajo sin servidor sin la complejidad de GKE.
Las migraciones de bases de datos deben completarse antes de que una nueva revisión de Cloud Run reciba tráfico.
Ejecute migraciones durante el inicio del contenedor y utilice una sonda de inicio de Cloud Run que solo pase después de que las migraciones sean exitosas.
Por qué: La sonda de inicio retrasa el enrutamiento del tráfico hasta que el contenedor esté completamente listo, asegurando que el esquema de la base de datos sea correcto antes de que se sirva cualquier solicitud.
Una aplicación GKE necesita escalar basándose en una métrica personalizada como la profundidad de la cola de Pub/Sub, no solo CPU/memoria.
Utilice el Horizontal Pod Autoscaler (HPA) configurado para leer métricas personalizadas de Cloud Monitoring.
Por qué: Esto permite que el autoescalado sea impulsado por la lógica de negocio o indicadores de carga específicos de la aplicación, proporcionando un escalado más preciso que las métricas de recursos genéricas.
Un servicio impulsado por mensajes debe procesar cada mensaje exactamente una vez, a pesar de los reintentos y las posibles entregas duplicadas.
Combine Pub/Sub (con entrega al menos una vez o exactamente una vez) con un consumidor idempotente. El consumidor rastrea los IDs de mensajes procesados en un almacén persistente (por ejemplo, Firestore, Memorystore).
Por qué: Pub/Sub garantiza la entrega, pero el consumidor es responsable de la idempotencia para manejar los reintentos a nivel de aplicación y lograr un procesamiento verdadero de "exactamente una vez".
Los eventos relacionados con la misma entidad (por ejemplo, un usuario específico) deben procesarse en el orden en que fueron generados.
Publique mensajes en Pub/Sub con una `orderingKey`. Habilite la ordenación de mensajes en la suscripción.
Por qué: Pub/Sub garantiza que los mensajes con la misma clave de ordenación se entregan en orden, mientras que los mensajes con diferentes claves pueden procesarse en paralelo para escalabilidad.
Asegurar que una tarea (por ejemplo, generar informe diario de usuario) se ejecute solo una vez, incluso si llegan múltiples eventos de activación.
Utilice Cloud Tasks. Cree tareas con nombres explícitos (por ejemplo, `report-userX-2024-10-26`). Cloud Tasks deduplicará las solicitudes para crear una tarea con un nombre existente.
Por qué: Esto descarga la lógica de deduplicación al servicio de colas, simplificando el código de la aplicación y evitando trabajo redundante.
Un mensaje de Pub/Sub falla consistentemente el procesamiento después de múltiples reintentos y está bloqueando la cola.
Configure un tema de mensajes no entregados (DLQ) en la suscripción de Pub/Sub y establezca un número máximo de intentos de entrega.
Por qué: Pub/Sub mueve automáticamente el mensaje "venenoso" al DLQ, permitiendo que otros mensajes sean procesados y preservando el mensaje fallido para su análisis.
Un proceso de negocio implica una secuencia de llamadas a servicios con lógica condicional, manejo de errores y largas esperas.
Utilice Cloud Workflows para definir y ejecutar la lógica de orquestación.
Por qué: Cloud Workflows es un orquestador sin servidor que gestiona el estado, los reintentos y las largas esperas, proporcionando mayor fiabilidad y visibilidad que las funciones encadenadas manualmente.
Un servicio de Cloud Function o Cloud Run solo debe activarse por eventos de la nube específicos (por ejemplo, ciertos tipos de archivos en Cloud Storage).
Utilice un disparador de Eventarc con filtrado CEL (Common Expression Language) en los atributos del evento.
Por qué: El filtrado ocurre antes de que se invoque el servicio, ahorrando costos y ciclos de cómputo al no procesar eventos irrelevantes.
Limitar la velocidad de las llamadas salientes a una API de terceros desde un servicio escalado horizontalmente como Cloud Run.
Ponga en cola las llamadas a la API como tareas en una cola de Cloud Tasks con `rateLimits` configurados (por ejemplo, envíos máximos por segundo).
Por qué: Cloud Tasks proporciona una limitación de velocidad centralizada y sin servidor que funciona en todas las instancias escaladas sin requerir contadores distribuidos complejos.
Autenticar de forma segura las llamadas entre dos servicios de Cloud Run (o Cloud Functions).
Conceda a la cuenta de servicio del servicio llamador el rol IAM `roles/run.invoker` en el servicio llamado. El llamador envía un token de ID firmado por Google con su solicitud.
Por qué: Este es el método nativo, seguro y sin claves para la autenticación de servicio a servicio, aprovechando la infraestructura de identidad de Google.
Un servicio impulsado por eventos necesita reaccionar a cambios a nivel de fila en una base de datos Cloud SQL casi en tiempo real.
Utilice Datastream (CDC) para transmitir cambios de la base de datos a Pub/Sub. Utilice Eventarc para activar un servicio de Cloud Run desde el tema de Pub/Sub.
Por qué: Este es un patrón desacoplado y fiable que evita el sondeo de la base de datos y no requiere modificar la aplicación que escribe en la base de datos.
Un proceso de negocio de larga duración debe pausarse para esperar un evento externo, como que un humano haga clic en un enlace de aprobación en un correo electrónico.
Utilice Cloud Workflows con un endpoint de callback. El workflow se pausa (hasta por un año) hasta que recibe una solicitud HTTP en su URL de callback única.
Por qué: Los callbacks permiten a los workflows esperar eventos externos sin consumir recursos de cómputo, lo que lo hace ideal para procesos de larga duración con intervención humana.
Una aplicación sin servidor sensible a la latencia experimenta respuestas iniciales lentas después de periodos de inactividad.
Configure `min-instances` a 1 o más. Para arranques en frío inevitables, utilice `startup-cpu-boost`. También optimice la aplicación (imagen más pequeña, inicialización más rápida).
Por qué: `min-instances` es la forma más efectiva de eliminar los arranques en frío pero incurre en costos. `startup-cpu-boost` acelera el proceso de inicio en sí.
Una solicitud es lenta o falla en múltiples microservicios, y el cuello de botella no es obvio a partir de los registros o métricas de servicios individuales.
Utilice Cloud Trace con propagación de contexto. Instrumente las aplicaciones para reenviar encabezados de traza (por ejemplo, W3C Trace Context).
Por qué: Cloud Trace proporciona una visualización en cascada de todo el ciclo de vida de la solicitud a través de todos los servicios, identificando la fuente de latencia o errores.
Una aplicación se ejecuta lentamente en producción y no está claro si el problema es debido a la CPU, una fuga de memoria o E/S.
Utilice Cloud Profiler para analizar continuamente el uso de CPU y heap en producción.
Por qué: Cloud Profiler identifica cuellos de botella de rendimiento a nivel de código (rutas calientes, fugas de memoria) con una sobrecarga muy baja, sin necesidad de reproducir problemas en un entorno de prueba.
Pasar de alertas de umbral simples (por ejemplo, "latencia > 500ms") a alertas más significativas basadas en Objetivos de Nivel de Servicio (SLOs).
Defina SLIs y SLOs en Cloud Monitoring. Cree políticas de alerta basadas en la "tasa de consumo" del presupuesto de errores.
Por qué: Las alertas de tasa de consumo son más sensibles a cambios significativos y menos ruidosas que las alertas de umbral simples, indicando cuándo se está en una trayectoria de incumplimiento de su SLO.
Agregue excepciones de aplicaciones de múltiples servicios para rastrear la frecuencia, ver rastreos de pila y recibir notificaciones de nuevos tipos de error.
Utilice Cloud Error Reporting.
Por qué: Error Reporting ingesta, agrupa y analiza automáticamente las excepciones de registros estructurados, proporcionando un panel centralizado para gestionar los errores de la aplicación.
Monitorear, visualizar y alertar sobre métricas de negocio personalizadas (por ejemplo, pedidos por minuto, registros de usuarios).
Instrumente el código de la aplicación utilizando el SDK de OpenTelemetry. Configure el exportador para enviar métricas a Cloud Monitoring.
Por qué: Este es el estándar moderno, agnóstico de proveedor, para instrumentación personalizada. Permite rastrear cualquier métrica y aprovechar todas las características de Cloud Monitoring para ello.