Cuando necesitas capturar millones de eventos por segundo y distribuirlos a diferentes destinos sin perder un solo mensaje, Pub/Sub de Google Cloud se convierte en una pieza fundamental de tu arquitectura de datos. A continuación se explican sus componentes, patrones de uso y cómo resolver los problemas más comunes al trabajar con mensajería en tiempo real.
¿Qué es Pub/Sub y por qué es clave para la ingesta de datos?
Pub/Sub es un servicio de mensajería que permite la ingesta y la entrega de eventos de forma escalable y persistente [0:20]. Al operar sobre la red global de Google Cloud, puede escalar de cero a millones de registros en pocos segundos, lo que lo hace ideal para escenarios de alta demanda.
Dentro de una arquitectura de referencia, Pub/Sub se ubica en la capa de captura [1:07]. Desde ahí se conecta con servicios de almacenamiento como Cloud Storage, de procesamiento como Dataflow y de análisis como BigQuery o Dataproc. Esta integración nativa con el ecosistema de Google Cloud simplifica la construcción de pipelines completos de datos.
¿Cómo fluyen los eventos desde el origen hasta el destino?
El flujo básico involucra tres elementos centrales [2:30]:
- Publisher: sistema que genera mensajes y los envía a Pub/Sub.
- Tópico: canal lógico dentro de Pub/Sub que recibe los mensajes.
- Subscriber: destino que consume los mensajes a través de una suscripción.
Un ejemplo práctico: los logs de una aplicación se envían a Pub/Sub, se suscriben a un tópico y se procesan con Dataflow para finalmente cargarlos en BigQuery [1:40]. Otro caso frecuente es tomar archivos desde Cloud Storage, conectarlos con Pub/Sub y enviarlos también a Dataflow para su transformación.
¿Qué patrones de publicación y suscripción se pueden configurar?
Pub/Sub ofrece flexibilidad para diseñar distintas combinaciones entre publicadores y suscriptores [3:10]:
- Un publisher, un subscriber: el patrón más simple; un productor envía mensajes a un tópico y un único consumidor los recibe.
- Múltiples publishers, múltiples subscribers: varios productores envían mensajes a un solo tópico y, mediante la suscripción, cada mensaje se dirige a un subscriber específico según su contenido.
- Un publisher con replicación: un productor genera mensajes hacia un tópico y se crean dos suscripciones independientes que replican los mismos mensajes a dos subscribers distintos [4:00].
Estos patrones permiten resolver prácticamente cualquier caso de uso de mensajería en una organización.
¿Cuál es la diferencia entre pull y push subscription?
Existen dos métodos de entrega de mensajes [4:35]:
- Pull subscription: el subscriber solicita activamente los mensajes a Pub/Sub.
- Push subscription: Pub/Sub envía los mensajes directamente al subscriber a través de un API REST endpoint.
En ambos casos, la entrega del mensaje está garantizada, aunque los mensajes pueden llegar en cualquier orden.
¿Cómo resolver problemas de orden y duplicación de mensajes?
Cuando el volumen de mensajes es muy alto, pueden presentarse dos situaciones frecuentes [5:10]:
- Mensajes fuera de orden: los eventos no llegan en la secuencia en que fueron generados.
- Mensajes duplicados: el mismo evento se entrega más de una vez.
La solución para ambos casos es integrar Pub/Sub con Dataflow [5:30]. Dataflow permite aplicar templates que reordenan los mensajes según su marca temporal original y filtran los duplicados mediante un proceso conocido como deduplicación. De esta forma se garantiza que el subscriber reciba exactamente los mensajes correctos y en el orden esperado.
Esta combinación de Pub/Sub con Dataflow es una de las estrategias más robustas para construir pipelines de datos en tiempo real dentro de Google Cloud. Si ya estás trabajando con eventos a gran escala, experimenta con estos patrones y comparte tu experiencia en los comentarios.
