Google PCD: Diseño de API, integración y desarrollo orientado a eventos — Guía de estudio

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

Forma parte de la Google Professional Cloud Developer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

La integración de aplicaciones modernas en Google Cloud combina APIs síncronas bien diseñadas con patrones asíncronos y orientados a eventos que son resilientes. El objetivo es proporcionar contratos claros, identidad sólida, manejo de errores consistente y controles operativos que mantengan la latencia baja y la disponibilidad alta incluso ante fallos, escalado o cambios. Esta sección cubre la elección de protocolos y APIs, gateways y autenticación, mensajería y enrutamiento de eventos, trabajo en segundo plano, orquestación, identidad y confianza entre servicios, patrones de fiabilidad, webhooks seguros y evolución segura de esquemas.

Diseño y Gestión de APIs

Elige el protocolo adecuado:

REST: Fácil de usar para humanos, cacheable a través de HTTP, ideal para APIs públicas y de socios. Usa un diseño orientado a recursos, métodos estándar, ETags y HATEOAS solo cuando aporten valor. Desventaja: contratos menos precisos que protobuf; potencial de sobre/sub-extracción de datos (over/under-fetching).
gRPC: Contratos con Protobuf, streaming bidireccional, transporte binario eficiente; muy adecuado para llamadas internas de servicio a servicio de baja latencia. Desventaja: el soporte en navegadores requiere gRPC-Web; la observabilidad y la compatibilidad para clientes públicos pueden ser más difíciles.
GraphQL: Consultas flexibles que reducen los viajes de ida y vuelta (round-trips) para vistas compuestas. Desventaja: resolvers complejos, riesgos de N+1, desafíos de caché y matices en el control de acceso.

Versionado y paginación:

Prefiere cambios aditivos y retrocompatibles. Usa versiones mayores basadas en la URI (p. ej., /v1) y revisiones menores a través de campos y feature flags. Descontinúa (depreca) con plazos claros.
Pagina con cursores estables o un nextPageToken para evitar páginas inconsistentes bajo cambios constantes; evita el uso de offset para conjuntos de datos grandes.

Validación y errores:

Usa OpenAPI para los esquemas de solicitud/respuesta de REST y reglas de validación de protobuf para gRPC.
Adopta un modelo de errores consistente: mapea a códigos de estado HTTP canónicos; para gRPC usa google.rpc.Status (código, mensaje, detalles). Incluye razones de error analizables por máquina y un ID de correlación. Evita filtrar detalles internos.

Opciones de gestión de APIs:

API Gateway: Gateway gestionado y ligero para backends OpenAPI/gRPC (Cloud Run, Cloud Functions, GKE, Compute Engine). Soporta autenticación, claves de API, validación de JWT, cuotas. Bueno para arquitecturas serverless y planos de control sencillos.
Cloud Endpoints (ESPv2): Desplegado junto a tu servicio; soporta transcodificación de OpenAPI o gRPC, autenticación, cuotas y métricas. Bueno cuando es preferible coubicar el proxy con la carga de trabajo.
Apigee: Gestión del ciclo de vida completo de la API con políticas avanzadas (contención de picos, cuotas, mediación, transformación, proveedores de OAuth, monetización, portal de desarrolladores). Ideal para ecosistemas de socios complejos y control norte-sur.

Autenticación y cuotas:

Para usuarios finales: OAuth 2.0 o Firebase Authentication; para servicios: ID tokens firmados por Google (OIDC) o tokens de cuenta de servicio OAuth (2-legged).
Aplica cuotas y contención de picos (spike arrest) cerca de los clientes (Apigee) y por consumidor (claves de API o credenciales de cliente) para proteger los backends.

Ejemplo mínimo de OpenAPI para API Gateway con backend de Cloud Run y 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

Mensajería Asíncrona y Gestión de Eventos

Fundamentos de Pub/Sub:

Los temas (topics) y las suscripciones desacoplan publicadores y consumidores. La entrega es al menos una vez (at-least-once); pueden ocurrir duplicados y cambios en el orden.
Usa confirmaciones (acknowledgments) y extiende los plazos de confirmación (ack deadlines) cuando el procesamiento es largo; aplica control de flujo en el cliente para evitar presión sobre la memoria.
Ordenamiento: habilita el ordenamiento de mensajes y proporciona una clave de ordenamiento (ordering key) para garantizar la entrega en orden por clave; mantén un único publicador activo por clave cuando sea posible.
Mensajes fallidos (Dead letters): configura temas de mensajes fallidos (dead-letter topics) para contener mensajes corruptos (poison messages) y prevenir reintentos infinitos; monitorea y clasifica.

Crear tema, suscripción y 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 del consumidor: implementa manejadores idempotentes y deduplicación (p. ej., por messageId o una clave de idempotencia a nivel de aplicación); reintenta errores transitorios con backoff; mueve los mensajes irrecuperables a la DLQ y alerta.

Eventarc y CloudEvents:

Eventarc enruta eventos desde servicios de Google Cloud, fuentes personalizadas y Audit Logs hacia Cloud Run, Cloud Functions o GKE. Los eventos usan la envoltura (envelope) de CloudEvents (id, source, type, subject, time).
Filtra por atributos (type, subject, location) en el disparador (trigger) para reducir el ruido y el costo. Usa cuentas de servicio dedicadas para el mínimo privilegio.

Crear un disparador de Eventarc para la finalización de objetos en 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

Compensaciones:

Pub/Sub está optimizado para pull y es resiliente para un alto rendimiento; Eventarc simplifica el enrutamiento desde productores que no controlas y usa push hacia tu servicio con metadatos estandarizados.
Para un orden estricto o límites estrictos de costo, considera particionar y limitar la tasa (rate-limiting) en los publicadores; para una distribución en abanico (fanout) de muy baja latencia, ajusta la concurrencia de los suscriptores con cuidado.

Orquestación, Trabajo en Segundo Plano y Procesos de Larga Duración

Cloud Tasks:

Colas de tipo push para llamadas HTTP en segundo plano de forma fiable. Establece la tasa de envío (dispatch rate) y la concurrencia por cola para proteger los backends. Configura reintentos con backoff exponencial y un número máximo de intentos.
Asegura la idempotencia con un nombre de tarea determinista o una cabecera Idempotency-Key y deduplica en el lado del servidor. Responde rápidamente (2xx) y realiza el trabajo pesado de forma asíncrona si es necesario.

Crear una cola con límites de tasa y reintentos:

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:

Orquesta procesos de negocio de múltiples pasos a través de HTTP y conectores de Google Cloud. Modela acciones de compensación (patrón saga) para fallos parciales; evita las transacciones distribuidas.
Usa tiempos de espera (timeouts) y políticas de reintento a nivel de paso; persiste el estado entre reintentos para poder reanudar después de interrupciones. Sondea (poll) las operaciones de larga duración y cancela si se excede el plazo.

Esquema de compensación:

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}

Guía operativa:

Prefiere Cloud Tasks para tareas HTTP en segundo plano de tipo “disparar y olvidar” (fire-and-forget) con un control preciso de la tasa hacia un solo servicio. Usa Pub/Sub para distribución en abanico (fanout) y múltiples consumidores. Usa Workflows cuando debas coordinar varias llamadas con lógica de bifurcación y compensación.

Identidad, confiabilidad e integraciones

Identidad de servicio a servicio y propagación de tokens:

Las cargas de trabajo de Cloud Run/Functions/Compute Engine/GKE deben usar cuentas de servicio con el mínimo privilegio. En GKE, usa Workload Identity para evitar las credenciales a nivel de nodo.
Para llamadas de Cloud Run a Cloud Run, usa un token de ID cuya audience coincida con la URL de destino. Propaga la identidad solo cuando el servicio descendente (downstream) deba actuar en nombre del llamador; de lo contrario, usa la cuenta de servicio del llamado.

Obtener un token de ID en 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"

Dependencias síncronas y resiliencia:

Establece tiempos de espera del cliente más bajos que los tiempos de espera del servicio ascendente (upstream); asigna un presupuesto por salto. Reintenta solo las operaciones idempotentes con truncated exponential backoff y jitter. Evita tormentas de reintentos limitando el tiempo total de reintento.
Usa circuit breakers (interruptores de circuito) para fallar rápidamente cuando un servicio ascendente no esté saludable; en GKE/Apigee/Envoy puedes configurar el máximo de solicitudes pendientes, la expulsión en caso de fallo y los sondeos de estado (health probes). Proporciona alternativas razonables o degrada el servicio de forma controlada.
Asigna los errores transitorios (429, 408, 500–503) a un comportamiento reintentable; trata los 4xx (distintos de 408/429) como no reintentables.

Webhooks e integraciones con terceros:

Verifica las solicitudes entrantes usando una cabecera de firma HMAC con un secreto compartido o un JWT firmado; para una mayor garantía, usa mTLS. Almacena los secretos en Secret Manager y rótalos regularmente.
Confirma la recepción rápidamente; encola en Cloud Tasks o publica en Pub/Sub para desacoplar el procesamiento pesado. Aplica límites de tasa (rate-limit) a las IP o claves entrantes para proteger los backends.
Webhooks salientes: incluye una Idempotency-Key para permitir reintentos seguros y verifica los certificados TLS y los nombres de host remotos.

Evolución de esquemas y compatibilidad:

REST/JSON: los campos aditivos son seguros; nunca reutilices ni cambies el tipo/significado de los campos existentes. Marca los campos como obsoletos (deprecated) y continúa sirviéndolos durante un período de tiempo.
Protobuf/gRPC: nunca reutilices los números de campo; usa etiquetas reservadas; prefiere campos opcionales; la semántica de valores predeterminados y de presencia es importante para la compatibilidad.
Eventos: incluye una dataVersion y mantén estables los atributos de CloudEvents; reserva espacio para extensiones. Con Pub/Sub, considera usar Pub/Sub Schema (Avro/Protobuf) para validar en el momento de la publicación.
Pruebas: usa pruebas de contrato orientadas al consumidor (consumer-driven contract tests), emuladores (Pub/Sub, Datastore/Firestore) o proyectos aislados, y lanzamientos canary. Ejecuta pruebas de integración en CI usando entornos efímeros y cuotas realistas para exponer fallos latentes.

Seguridad y cuotas en toda la pila:

Aplica la autenticación en el borde (edge) (API Gateway/Apigee/Endpoints) y en el servicio. Aplica cuotas por consumidor y spike arrest (detención de picos).
Monitoriza los picos de 401/403 y las tasas de 429 para ajustar el backoff del cliente y las cuotas.
Registra los ID de solicitud en todos los componentes y propaga las cabeceras de trazabilidad (Traceparent o X-Cloud-Trace-Context) para una observabilidad de extremo a extremo.

Escenario de problema práctico

AcmeRetail está construyendo un servicio de click-to-collect (compra en línea y recoge en tienda) en Google Cloud. Una aplicación web en React llama a una API pública para realizar pedidos; los servicios de backend deben reservar inventario, procesar pagos y notificar a las tiendas. El equipo necesita API de baja latencia, procesamiento en segundo plano confiable, actualizaciones basadas en eventos y una reversión (rollback) segura en caso de fallos parciales.

Enfoque:

Exponer una API REST pública a través de API Gateway frente a un servicio de pedidos en Cloud Run.

Justificación: REST con JSON es simple para los navegadores; API Gateway valida los JWT de Firebase Auth, aplica claves de API y cuotas por cliente, y termina la conexión en el borde. Cloud Run autoescala con los picos de tráfico.

Implementar llamadas de servicio a servicio con gRPC para las rutas internas críticas (hot paths) (pedidos a inventario, precios).

Justificación: gRPC reduce la sobrecarga de serialización y proporciona contratos estrictos. Usar Workload Identity (GKE) o cuentas de servicio (Cloud Run) y OIDC entre servicios. Los tiempos de espera se establecen en 300 ms con dos reintentos y jitter para lecturas idempotentes.

Usar Workflows para orquestar la saga del pedido: cobrar el pago, reservar el inventario, crear la tarea de recogida; compensar en caso de fallo.

Justificación: La orquestación centralizada gestiona los pasos de larga duración y las compensaciones. Si la reserva falla, Workflows activa un reembolso y devuelve un 409 al cliente.

Publicar eventos de dominio en los temas de Pub/Sub orders e inventory para consumidores descendentes (downstream) (analítica, notificaciones a tiendas).

Justificación: Distribución en fanout sin acoplamiento fuerte. Los suscriptores implementan idempotencia usando orderId como clave. Las suscripciones tienen temas de mensajes no entregados (dead-letter topics) con max-delivery-attempts=10, y se disparan alertas si la DLQ crece.

Disparar notificaciones a las tiendas a través de Eventarc hacia un servicio notificador en Cloud Run ante cambios relevantes en Cloud Storage y Firestore.

Justificación: Eventarc enruta solo los eventos necesarios usando filtros de atributos; CloudEvents asegura metadatos consistentes. El notificador publica en proveedores de SMS/Email de terceros usando Cloud Tasks para controlar la tasa y los reintentos.

Gestionar los webhooks del proveedor de pagos con un endpoint dedicado en Cloud Run, precedido por API Gateway, verificando firmas HMAC y usando Cloud Tasks para el procesamiento.

Justificación: Una confirmación rápida con un 200 reduce los reintentos del proveedor; Tasks asegura los reintentos con backoff. Los secretos se almacenan en Secret Manager; los cuerpos de las solicitudes se validan contra el esquema de OpenAPI.

Aplicar patrones de confiabilidad: circuit breakers en Apigee o Envoy para llamadas salientes al proveedor de pagos; tiempos de espera del cliente establecidos por debajo de los SLA del proveedor; reintentos con truncated exponential backoff para 429/5xx.

Justificación: Previene fallos en cascada y tormentas de reintentos, respeta los límites de terceros y convierte la sobrecarga transitoria en una degradación controlada.

Adoptar controles de evolución de esquemas: Protobuf para gRPC interno con campos reservados; las respuestas REST usan cambios aditivos en JSON; Pub/Sub usa la validación de esquemas Protobuf en el momento de la publicación.

Justificación: Mantiene la compatibilidad con los consumidores. Las pruebas de contrato e integración se ejecutan en Cloud Build en cada merge; los despliegues canary validan el tráfico real de forma segura.

Observar y operar: propagar las cabeceras de trazabilidad entre API Gateway y los servicios; exportar métricas de Cloud Logging para las tasas de error y el tamaño de la DLQ; alertar sobre el consumo del SLO (SLO burn) y anomalías de 429/5xx.

Justificación: Detección rápida de regresiones, problemas de cuota o incidentes del proveedor; los SRE pueden ajustar las cuotas y las políticas de backoff rápidamente.

← Cómputo · Todos los dominios · Datos de aplicación →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →