La columna de integración trajo de AWS los principios que no se renegocian: entre servicios lo asíncrono es diseño, toda cola lleva DLQ, todo consumidor es idempotente, y el agente autónomo no espera trabajo — el trabajo lo despierta por cola, evento o reloj. GCP implementa el mismo cuadro con las piezas reagrupadas, y una de ellas no tiene equivalente directo en AWS.

Función	En AWS	En GCP
Cola de trabajo	SQS	Pub/Sub (suscripción pull)
Publicar en abanico	SNS	Pub/Sub (múltiples suscripciones)
Cola que empuja a HTTP con ritmo	— (no hay directo)	Cloud Tasks
Bus de eventos con reglas	EventBridge	Eventarc
Reloj / cron administrado	EventBridge Scheduler	Cloud Scheduler
Puerta de entrada de APIs	API Gateway	API Gateway / Apigee

La tesis del módulo

Pub/Sub colapsa la distinción SQS/SNS de AWS: todo es un topic, y cada suscripción decide si es cola (un consumidor procesa) o abanico (todos se enteran) — y además si el mensaje se retira (pull) o se empuja (push) al consumidor. El diseño ya no elige servicio según el patrón: elige forma de suscripción. Y Cloud Tasks cubre el hueco que en AWS se improvisaba: la cola cuyo destino es un endpoint HTTP, con control de ritmo incorporado — hecha a la medida de despertar Cloud Run sin ahogarlo.

Pub/Sub: un servicio, los dos patrones

En Pub/Sub se publica a un topic; los consumidores crean suscripciones. La gramática:

Una suscripción compartida por N instancias del consumidor = la cola de SQS: cada mensaje lo procesa uno, los no confirmados reaparecen (el visibility timeout se llama ack deadline), y la suscripción lleva su DLQ (dead-letter topic) con el mismo argumento no negociable del curso de AWS.
Varias suscripciones al mismo topic = el abanico de SNS: cada suscripción recibe su copia completa. El evento “cotización enviada” con una suscripción para el agente de seguimiento y otra para analítica — sin servicio extra ni configuración puente.
Pull vs. push: la suscripción pull la drena el consumidor a su ritmo (el patrón de workers); la push empuja cada mensaje como petición HTTP — hecha para Cloud Run services, con la autenticación resuelta por service account (módulos 2 y 4 pagando dividendos otra vez).

Las garantías que obligan a la disciplina de siempre: entrega al menos una vez y orden no garantizado por defecto (hay claves de orden opcionales, con costo de throughput — la cola FIFO de esta nube). La idempotencia del consumidor sigue siendo ley; el argumento completo vive en el módulo de AWS y no se repite.

Cloud Tasks: la pieza sin equivalente

Cloud Tasks es una cola cuyo destino es un endpoint HTTP concreto, con dos controles que Pub/Sub no da: ritmo máximo de entrega (X peticiones/segundo hacia el destino) y programación por tarea (esta tarea, a esta hora). Sus casos naturales en la plataforma de agentes:

Proteger un destino frágil: el CRM que tolera 5 llamadas/segundo recibe exactamente eso, sin que el consumidor implemente throttling.
Trabajo diferido puntual: “reintenta esta cotización en 4 horas” — una tarea programada, no un cron ni un contenedor esperando.
El fan-out controlado hacia Cloud Run: miles de tareas encoladas drenándose al ritmo que el servicio (y el presupuesto del módulo 8) aguanta.

La regla de reparto: Pub/Sub para eventos y colas de trabajo entre servicios; Cloud Tasks cuando el destino es un HTTP específico que necesita ritmo o cita. Si dudas, pregunta quién manda: en Pub/Sub manda el consumidor (drena a su ritmo); en Tasks manda la cola (entrega al ritmo configurado).

Eventarc y Scheduler: los otros dos despertadores

Eventarc enruta eventos de servicios de Google (un archivo subido a Storage, una fila en la auditoría) y propios hacia Cloud Run — el EventBridge de esta nube, con los eventos de infraestructura incluidos. Cloud Scheduler es el cron administrado que dispara el job nocturno. El diagrama del despertar del curso de AWS se traduce entero:

      QUIÉN DESPIERTA AL AGENTE (GCP)

  correo llega     cada noche 2am     archivo en bucket
       │                │                   │
       ▼                ▼                   ▼
  ┌─────────┐    ┌─────────────┐      ┌───────────┐
  │ Pub/Sub │    │ Cloud       │      │ Eventarc  │
  │ (+ DLQ) │    │ Scheduler   │      │ (regla)   │
  └────┬────┘    └──────┬──────┘      └─────┬─────┘
       │                │                   │
       └───────────┬────┴───────────────────┘
                   ▼
           ┌───────────────┐
           │ Cloud Run     │
           │ (job/service  │
           │  efímero)     │
           └───────────────┘

Ojo — push no exime de idempotencia ni de límites: la suscripción push que empuja a tu Cloud Run se siente síncrona y es fácil olvidar que sigue siendo al menos una vez (duplicados posibles) y que un pico de publicación es un pico de peticiones a tu servicio. La clave de deduplicación sigue en el camino caliente, y si el destino necesita protección de ritmo, la respuesta es Cloud Tasks — no rezar.

Sobre la puerta de entrada: API Gateway (y Apigee para la versión enterprise) juega el papel exacto del API Gateway de AWS — autenticar, limitar, desacoplar la entrada — y las herramientas del agente siguen siendo APIs internas concretas, idealmente MCP, corriendo como cualquier microservicio de la plataforma. Sin novedades: los argumentos del curso de AWS aplican línea por línea.

Errores comunes

Buscar “el SQS de GCP” y “el SNS de GCP” como servicios separados. Ambos son Pub/Sub con distinta forma de suscripción. Traducir servicio-a-servicio en vez de patrón-a-forma produce arquitecturas con piezas de más.
Suscripciones sin dead-letter topic. El mensaje venenoso no lee documentación de Google: reintenta infinito igual. DLQ en toda suscripción, con alarma.
Usar Pub/Sub push como si garantizara una sola entrega. Push cambia quién inicia la petición, no las garantías. Idempotencia en el consumidor, siempre.
Improvisar throttling que Cloud Tasks regala. Semáforos artesanales delante del CRM frágil, con Tasks a un binding de distancia. La pieza existe; úsala.
Cron dentro de un contenedor. El mismo anti-patrón de todas las nubes: Scheduler dispara, el job nace. Un proceso vivo mirando el reloj es dinero mirando el reloj.
Elegir pull o push por costumbre. Workers que drenan a su ritmo = pull; Cloud Run que escala con las peticiones = push (o Tasks si hace falta ritmo). Es una decisión por consumidor, no una preferencia de equipo.

La frase para llevarse

“En GCP la pregunta no es qué servicio de mensajería sino qué forma de suscripción: una compartida es cola, varias son abanico, push empuja y pull drena. Cloud Tasks cubre el destino HTTP con ritmo, Scheduler pone el reloj — y la idempotencia sigue siendo ley, porque ‘al menos una vez’ tampoco cambió de nube.”

Qué viene

Módulo 6: estado y datos. El reparto por forma de acceso viaja intacto; las casas cambian: Firestore por DynamoDB (con modelo de documentos, no clave-valor), Cloud SQL y AlloyDB para lo relacional con pgvector, y dos piezas que mueven la decisión vectorial y analítica — Vertex AI Vector Search como índice dedicado, y BigQuery: el almacén analítico serverless que en GCP es protagonista y que cambia dónde viven los datos fríos de la plataforma.

Arquitectura GCP — Módulo 5: integración, Pub/Sub y los despertadores