Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen PCDE. Lee de arriba a abajo o salta a una sección.
Plataforma global de e-commerce que requiere transacciones ACID, fuerte consistencia y 99.999% de disponibilidad en múltiples continentes.
Cloud Spanner con una configuración multirregional (p. ej., nam-eur-asia).
Por qué: Spanner es el único servicio administrado de GCP que proporciona transacciones ACID globalmente distribuidas y fuertemente consistentes a escala con un SLA del 99.999%.
Migrar una base de datos Oracle OLTP grande y de alto rendimiento con procedimientos almacenados complejos y necesidades de consultas analíticas.
AlloyDB para PostgreSQL.
Por qué: AlloyDB ofrece un rendimiento superior de PostgreSQL, características de compatibilidad con Oracle y un motor columnar para acelerar las consultas analíticas (HTAP) sin afectar las cargas de trabajo transaccionales.
Ingesta de datos de series temporales de alto rendimiento (millones de OPS) (p. ej., IoT, registros) que requiere lecturas de baja latencia y expiración automática de datos.
Cloud Bigtable con un diseño de clave de fila de `(entity_id)#(reverse_timestamp)` y una política de recolección de basura.
Por qué: Bigtable está diseñado para cargas de trabajo clave/valor masivas y de baja latencia. Una marca de tiempo inversa en la clave de fila co-ubica datos recientes para escaneos eficientes. La recolección de basura maneja el TTL.
Aplicación móvil o web que requiere un esquema flexible, sincronización de datos en tiempo real con los clientes y soporte fuera de línea.
Firestore en modo nativo.
Por qué: Firestore está diseñado específicamente para este patrón de backend de aplicación sin servidor, proporcionando oyentes en tiempo real y persistencia fuera de línea a través de sus SDK de cliente de forma predeterminada.
Búsqueda de similitud a gran escala (más de 10 millones de vectores) para aplicaciones de IA/ML (p. ej., RAG, recomendaciones) que necesitan una latencia inferior a 100 ms.
AlloyDB para PostgreSQL con extensión pgvector y un índice ScaNN.
Por qué: AlloyDB integra el algoritmo ScaNN de alto rendimiento de Google para la búsqueda aproximada del vecino más cercano (ANN), superando las implementaciones estándar de búsqueda vectorial a escala.
Diseñar un esquema de Cloud Spanner para una carga de trabajo con muchas escrituras para evitar puntos críticos en un solo servidor.
Diseñar claves primarias que no utilicen valores que aumentan monótonamente (p. ej., IDs secuenciales, marcas de tiempo) como la primera parte de la clave. En su lugar, utilice UUIDs, valores hash o secuencias de bits invertidos.
Por qué: Spanner distribuye los datos lexicográficamente por clave primaria. Las claves secuenciales dirigen todas las escrituras a una única división, creando un punto crítico. Las claves distribuidas aleatoriamente distribuyen las escrituras en todas las divisiones.
Un esquema de Spanner tiene una fuerte relación padre-hijo (p. ej., Clientes y Pedidos) y las consultas frecuentemente recuperan un padre con todos sus hijos.
Utilizar tablas intercaladas, definiendo la tabla hija con `INTERLEAVE IN PARENT`.
Por qué: El intercalado co-ubica físicamente las filas hijas con su fila padre en el almacenamiento. Esto hace que las uniones padre-hijo sean extremadamente eficientes, ya que se convierte en un escaneo de rango altamente optimizado en una sola división.
Rastreo de ubicaciones en tiempo real para una flota masiva de vehículos (más de 50k escrituras/seg) con consultas para encontrar vehículos dentro de un área geográfica.
Cloud Bigtable con una clave de fila prefijada por un GeoHash de la ubicación del vehículo.
Por qué: Bigtable maneja el rendimiento de escritura extremo. La codificación GeoHash convierte coordenadas 2D en una cadena 1D donde los prefijos representan la proximidad geográfica, lo que permite escaneos de rango geoespaciales eficientes.
Almacenar y analizar datos a escala de petabytes (p. ej., datos genómicos, registros) con consultas SQL analíticas complejas.
Almacenar datos sin procesar en Cloud Storage y consultarlos directamente desde BigQuery usando tablas externas, o cargarlos en el almacenamiento nativo de BigQuery.
Por qué: BigQuery es un almacén de datos sin servidor construido para análisis a escala de petabytes. Su separación de almacenamiento y cómputo proporciona un rendimiento de consulta inigualable y rentabilidad para cargas de trabajo OLAP.
Una caché en memoria de alta disponibilidad para estructuras de datos complejas (hashes, conjuntos) con capacidades de pub/sub para invalidación de caché.
Memorystore para Redis Standard Tier con réplicas de lectura.
Por qué: Standard Tier proporciona un SLA del 99.9% con conmutación por error automática. Redis admite tipos de datos complejos y pub/sub, a diferencia de Memcached. Las réplicas de lectura pueden escalar el rendimiento de lectura.
Diseñar una aplicación SaaS multi-inquilino en Spanner que requiera una fuerte aislamiento de datos y garantías de rendimiento por inquilino.
Usar tenant_id como primer componente de la clave primaria para todas las tablas. Para un aislamiento más fuerte, usar un modelo de base de datos por inquilino dentro de una única instancia de Spanner.
Por qué: Un prefijo tenant_id co-ubica naturalmente todos los datos de un solo inquilino, optimizando las consultas y permitiendo que Spanner divida los datos por inquilino. La base de datos por inquilino proporciona el aislamiento lógico más fuerte.
Una base de datos de Cloud SQL está experimentando un rendimiento de consulta lento y un alto uso de CPU.
Utilizar Query Insights para identificar las consultas que consumen más recursos, analizar sus planes de ejecución e identificar índices faltantes o patrones ineficientes.
Por qué: Query Insights es la herramienta principal y integrada para diagnosticar el rendimiento de las consultas en Cloud SQL. Visualiza la carga de consultas, identifica los eventos de espera y ayuda a identificar la causa raíz sin herramientas de terceros.
Una organización necesita un único panel y un conjunto de políticas de alerta para docenas de instancias de bases de datos distribuidas en múltiples proyectos de GCP.
Crear un espacio de trabajo de Cloud Monitoring en un proyecto central y configurar su "alcance de métricas" para incluir todos los proyectos que contengan instancias de bases de datos.
Por qué: Los alcances de métricas permiten que un único espacio de trabajo de Monitoring agregue y muestre métricas de múltiples proyectos, proporcionando una vista unificada sin duplicación de datos ni configuraciones complejas.
Necesidad de aprovisionar y administrar instancias de Cloud SQL en entornos de desarrollo, preproducción y producción de manera consistente y con control de versiones.
Utilizar Terraform con el proveedor de Google Cloud. Definir un módulo de Cloud SQL y usar archivos `.tfvars` separados para cada entorno.
Por qué: Terraform proporciona Infraestructura como Código (IaC), lo que permite implementaciones repetibles, auditables y con control de versiones. Esto evita errores de configuración manual y garantiza la coherencia entre entornos.
Un contratista necesita acceso temporal elevado a la base de datos que debe revocarse automáticamente después de 4 horas.
Conceder el rol de IAM necesario con una Condición de IAM que use una expresión basada en el tiempo (`request.time < timestamp(...)`).
Por qué: Las Condiciones de IAM proporcionan una forma nativa y segura de conceder acceso por tiempo limitado sin necesidad de una limpieza manual, que es propensa a errores. El acceso se deniega automáticamente después de que expira la marca de tiempo.
Una política de seguridad requiere que todo el cifrado de disco de la base de datos utilice claves administradas por el cliente (CMEK) con rotación controlada.
Configurar la instancia de Cloud SQL o AlloyDB para usar una clave de Cloud KMS. Configurar la rotación automática en la clave de KMS.
Por qué: CMEK proporciona control y auditabilidad sobre las claves utilizadas para el cifrado en reposo. Cloud KMS maneja la gestión del ciclo de vida de las claves, incluida la rotación automatizada, de manera transparente.
El cumplimiento requiere capturar todas las consultas SQL ejecutadas en una instancia de Cloud SQL para PostgreSQL, con registros retenidos durante 7 años.
Habilitar la extensión `pgaudit` en la instancia. Configurar Cloud Audit Logs para el acceso a datos. Crear un sumidero de registros desde Cloud Logging a BigQuery para retención y análisis a largo plazo.
Por qué: pgaudit proporciona auditorías detalladas a nivel de SQL. Enviar registros a BigQuery es el patrón estándar y rentable para la retención de registros a largo plazo y con capacidad de búsqueda más allá del valor predeterminado de Cloud Logging.
Los analistas de datos necesitan ejecutar consultas analíticas pesadas en datos de producción de Cloud SQL sin afectar la carga de trabajo transaccional.
Crear una réplica de lectura y dirigir todas las consultas analíticas a ella. Para análisis más complejos, utilizar consultas federadas de BigQuery contra la réplica de lectura.
Por qué: Una réplica de lectura aísla completamente el tráfico de lectura analítico de la instancia principal, protegiendo el rendimiento OLTP. La federación permite usar el potente motor de BigQuery sin una canalización ETL separada.
Un clúster de Bigtable muestra una carga de CPU desigual, con algunos nodos muy utilizados mientras que otros están inactivos, lo que indica un cuello de botella en el rendimiento.
Utilizar la herramienta Key Visualizer en la Cloud Console para analizar los patrones de acceso e identificar los rangos de claves de fila específicos a los que se accede con demasiada frecuencia (hotspotting).
Por qué: Key Visualizer es la herramienta de diagnóstico especialmente diseñada para problemas de rendimiento de Bigtable. Proporciona un mapa de calor del acceso a las claves, lo que facilita la identificación de los puntos críticos que deben abordarse mediante el rediseño del esquema.
Necesidad de replicar cambios de una base de datos OLTP de Cloud SQL a un almacén de datos de BigQuery casi en tiempo real.
Usar Datastream para configurar un flujo de Change Data Capture (CDC) desde la instancia de Cloud SQL de origen directamente a BigQuery.
Por qué: Datastream es un servicio CDC administrado de baja latencia que lee los registros de la base de datos, minimizando el impacto en el origen. Maneja la deriva del esquema y entrega los cambios de manera confiable a BigQuery.
Una aplicación de Cloud Run está agotando las conexiones a la base de datos debido a la rápida escalabilidad durante los picos de tráfico.
Implementar el Cloud SQL Auth Proxy como un contenedor sidecar y configurarlo para el agrupamiento de conexiones (o usarlo con un agrupador dedicado como PgBouncer).
Por qué: Las plataformas sin servidor pueden escalar a miles de instancias, superando los límites de conexión de la base de datos. Un agrupador de conexiones multiplexa estas numerosas y efímeras conexiones de aplicaciones en un conjunto pequeño y estable de conexiones de base de datos.
Migrar una gran base de datos MySQL local (5TB) a Cloud SQL para MySQL con un tiempo de inactividad máximo de 30 minutos.
Utilizar el Servicio de Migración de Bases de Datos (DMS) para configurar un trabajo de replicación continua. DMS realiza una carga inicial y luego transmite los cambios hasta el cutover.
Por qué: DMS es la solución administrada para migraciones con tiempo de inactividad mínimo. La replicación continua significa que el único tiempo de inactividad es el tiempo que se tarda en detener las escrituras, esperar la sincronización final y apuntar la aplicación a la nueva base de datos.
Migrar una base de datos Oracle a AlloyDB para PostgreSQL, incluyendo procedimientos almacenados PL/SQL complejos.
Usar DMS para la migración de datos. Usar herramientas de conversión de esquemas (como Ora2Pg o DMS Schema Conversion) para convertir esquemas y PL/SQL a PL/pgSQL, seguido de revisión y pruebas manuales.
Por qué: Las migraciones heterogéneas requieren tanto la migración de datos (gestionada por DMS) como la conversión de esquemas/código. Las herramientas automatizadas manejan aproximadamente el 80% de la conversión, pero siempre se requiere esfuerzo manual para las características específicas de Oracle.
Necesidad de verificar la integridad y completitud de los datos después de migrar una base de datos desde un centro de datos local a Google Cloud.
Utilizar la herramienta de validación de datos (DVT) de código abierto. Configurar para comparar recuentos de filas, agregaciones a nivel de columna (min, max, sum) y hashes a nivel de fila entre el origen y el destino.
Por qué: DVT proporciona un marco completo, escalable y personalizable para la validación de datos que va más allá de los simples recuentos de filas, detectando problemas sutiles de corrupción o transformación de datos.
Migrar una aplicación MySQL fragmentada a una única base de datos globalmente consistente.
Utilizar múltiples trabajos de Dataflow paralelos para migrar cada fragmento concurrentemente a una única base de datos de Cloud Spanner. Rediseñar el esquema para eliminar la necesidad de fragmentación a nivel de aplicación.
Por qué: Spanner está diseñado para reemplazar arquitecturas fragmentadas complejas. Un enfoque de migración paralelo con Dataflow es la forma más eficiente en tiempo de consolidar grandes conjuntos de datos fragmentados en Spanner.
Migrar una base de datos SQL Server que utiliza Autenticación de Windows (Active Directory) a Cloud SQL para PostgreSQL.
Integrar Cloud SQL con Cloud Identity usando la autenticación de base de datos de IAM. Sincronizar grupos de AD con Google Groups a través de GCDS y mapear roles de base de datos a estos grupos.
Por qué: Este enfoque replica el modelo de control de acceso centralizado y basado en grupos de AD de una manera nativa de la nube, evitando la gestión manual de usuarios/contraseñas y aprovechando las estructuras de identidad existentes.
Migrar una aplicación de Amazon DynamoDB a Cloud Bigtable.
Mapear la clave primaria compuesta de DynamoDB (clave de partición + clave de ordenación) a una clave de fila concatenada de Bigtable, separada por un delimitador (p. ej., `partitionKey#sortKey`).
Por qué: Este diseño de clave de fila conserva las capacidades de consulta de la clave compuesta de DynamoDB, lo que permite búsquedas eficientes por prefijo de clave de partición y escaneos de rango en la porción de clave de ordenación.
Una aplicación que se conecta a una instancia de Cloud SQL de alta disponibilidad debe sobrevivir a una conmutación por error zonal sin intervención manual.
Conectarse a la base de datos utilizando el Cloud SQL Auth Proxy con el nombre de conexión de la instancia (proyecto:región:instancia), no una dirección IP estática.
Por qué: La dirección IP de la instancia cambia durante una conmutación por error. El Auth Proxy y el nombre de conexión de la instancia proporcionan un punto final estable que resuelve automáticamente la dirección IP de la instancia principal actual.
Una aplicación global de Spanner tiene usuarios en Norteamérica y Asia. Las escrituras se originan principalmente en NA, pero los usuarios asiáticos necesitan lecturas de baja latencia.
Usar una configuración multirregional con la región líder en Norteamérica (`nam*`). Las lecturas en Asia serán atendidas por réplicas de solo lectura locales.
Por qué: Las escrituras en Spanner se enrutan a través de la región líder, por lo que colocarla cerca de la fuente de escritura minimiza la latencia de escritura. Las réplicas de lectura en otras regiones proporcionan lecturas de baja latencia para usuarios distribuidos globalmente.
Una aplicación respaldada por AlloyDB tiene una relación de lectura-escritura de 10:1 y necesita escalar para manejar un alto tráfico de lectura mientras mantiene una disponibilidad del 99.99%.
Configurar la instancia principal con alta disponibilidad y agregar múltiples instancias de grupos de lectura. Dirigir el tráfico de lectura al grupo de lectura.
Por qué: La alta disponibilidad de AlloyDB proporciona el SLA del 99.99%. Las instancias de grupos de lectura están diseñadas para el escalado horizontal de lectura, descargando el tráfico de la instancia principal a nodos dedicados optimizados para lectura.
Una instancia de Cloud SQL sensible a la latencia con almacenamiento SSD tiene un rendimiento de E/S insuficiente.
Aumentar el tamaño de almacenamiento aprovisionado de la instancia.
Por qué: En Cloud SQL, tanto las IOPS de lectura como las de escritura escalan linealmente con la cantidad de almacenamiento de disco persistente aprovisionado. Aumentar el tamaño del disco es la forma directa de aumentar las IOPS disponibles.
Necesidad de implementar un cambio de esquema arriesgado en una base de datos crítica de Cloud SQL con capacidad de reversión rápida.
Crear una réplica de lectura de la instancia de producción (azul). Promover la réplica a una instancia independiente (verde), aplicar y validar los cambios de esquema. Luego, redirigir el tráfico de la aplicación a la instancia verde. Mantener la instancia azul en funcionamiento para la reversión.
Por qué: Este patrón permite realizar pruebas completas de los cambios en una copia de los datos a escala de producción sin afectar el sistema en vivo. El tráfico se puede cambiar instantáneamente, y la reversión es tan simple como apuntar el tráfico de nuevo a la instancia azul.
Necesidad de probar un plan de recuperación ante desastres de la base de datos trimestralmente sin afectar el entorno de producción.
Crear una instancia de prueba temporal restaurando desde una copia de seguridad de producción reciente. Ejecutar los procedimientos de DR documentados contra esta instancia de prueba, incluyendo pruebas simuladas de conmutación por error y reconexión de la aplicación.
Por qué: Las pruebas en una copia de seguridad restaurada proporcionan un entorno realista para validar el RTO/RPO y los procedimientos de recuperación sin el riesgo de causar una interrupción en la producción.
Un servicio de Cloud Run necesita conectarse a una instancia de Cloud SQL de forma segura sin que el tráfico atraviese la internet pública.
Configurar Cloud SQL con una IP privada. Crear un conector de acceso VPC sin servidor en la misma VPC y configurar el servicio de Cloud Run para enrutar el tráfico a través de él.
Por qué: Este es el patrón estándar y seguro para conectar la computación sin servidor a los recursos nativos de VPC. El conector une el entorno sin servidor y su VPC, manteniendo todo el tráfico en la red privada de Google.
Agregar una nueva columna no nula a una tabla masiva de Cloud Spanner con escritura activa sin tiempo de inactividad.
1. Agregar la columna como nula. 2. Actualizar el código de la aplicación para escribir en la nueva columna. 3. Rellenar las filas existentes en lotes usando Dataflow. 4. Después del relleno, alterar la columna para que sea NOT NULL.
Por qué: Este proceso de varios pasos es el patrón estándar de cambio de esquema en línea para tablas grandes. Evita bloquear la tabla durante un largo período o causar una operación de relleno masiva que impacte el rendimiento en una sola transacción.