Nylas y Google Pub/Sub: notificaciones sin perder eventos

El problema que nadie ve venir con los webhooks

Todo parece funcionar bien con tu webhook hasta el día en que Nylas sincroniza una cuenta con miles de correos y dispara varios miles de eventos message.created en menos de un minuto. Tu endpoint empieza a responder lento, acumula timeouts y comienza a perder entregas. No es un bug de tu código — es una limitación estructural del modelo HTTP tradicional para notificaciones de alto volumen.

El problema es simple: un webhook HTTP necesita que tu servidor esté siempre disponible, sea rápido y pueda absorber bursts. Cuando no puede, los eventos se pierden. Y en integraciones de email o calendario para empresas, perder un evento puede significar un correo sin procesar, una cita sin sincronizar o un flujo de negocio roto.

Existe una alternativa que cambia completamente el modelo: en lugar de que Nylas llame a tu servidor, tú le dices a Nylas que publique las notificaciones directamente en un topic de Google Cloud Pub/Sub. El queue deja de ser algo que tú construyes encima del webhook — se convierte en el mecanismo de entrega en sí mismo.

¿Qué es un canal Pub/Sub en Nylas y cómo funciona?

Un canal de Pub/Sub en Nylas es una configuración almacenada que le dice al servicio: "en lugar de hacer un POST a esta URL, publica los eventos en este topic de Google Cloud". El topic es tuyo — tú lo creas en tu proyecto de GCP, le otorgas permisos de publicación a Nylas, y a partir de ese momento los eventos fluyen hacia ahí.

Los payloads son exactamente los mismos que recibirías por HTTP: message.created, event.updated, y todos los demás triggers que ya conoces. La diferencia está en cómo llegan. En lugar de un request a tu servidor, aparecen en el topic y tus consumidores los leen desde una suscripción, a su propio ritmo.

Crear el canal es un solo comando desde la CLI de Nylas:

nylas webhook pubsub create --topic "projects/mi-proyecto/topics/nylas-email" --triggers message.created,message.updated

O un POST a /v3/channels/pubsub desde tu backend si prefieres la API directamente. Una vez activo, Nylas empieza a publicar en el topic en cuestión de minutos.

Las ventajas concretas frente a un webhook HTTP

La primera y más importante es la garantía de entrega. Si tu consumidor se cae, los mensajes no se pierden — esperan en la suscripción hasta que el servicio vuelva a estar disponible. Un webhook HTTP no puede darte eso sin que tú construyas una capa de reintentos encima.

La segunda ventaja es la segmentación por volumen. Puedes tener un topic para notificaciones de email de alto volumen y otro separado para eventos de calendario. Un sync masivo de correos no bloquea ni retrasa a los consumidores que están leyendo el canal de calendario. Esa separación vive en la infraestructura de Google, no en tu código.

La tercera es el dead-letter topic. Cuando un consumidor no puede procesar un mensaje después de varios reintentos, Pub/Sub lo mueve a un topic secundario en lugar de dejarlo acumularse en tu suscripción principal. Cuando corriges el problema — un bug, un cambio de schema, una caída de un servicio externo — puedes reprocesar esos mensajes y recuperar los eventos que de otra forma se habrían perdido.

Y por si tu infraestructura vive en AWS en lugar de GCP, Nylas ofrece la misma idea con Amazon SNS mediante canales /v3/channels/sns, con un IAM role que Nylas asume para publicar. El modelo es idéntico, solo cambia el cloud.

¿Cómo aplica esto en empresas de Perú y LATAM?

En la región, muchas integraciones de email y calendario en sistemas empresariales — ERPs, CRMs, plataformas de atención al cliente — se construyen con webhooks directos porque es lo más rápido de implementar. Y funciona bien... hasta que el volumen crece.

Una empresa que automatiza la gestión de correos de clientes en su ERP, o que sincroniza calendarios de equipos comerciales, puede llegar rápidamente a escenarios donde cientos o miles de eventos llegan en ráfagas cortas. Especialmente si están migrando datos históricos o sincronizando cuentas por primera vez.

El patrón Pub/Sub no es solo para empresas grandes. Es relevante para cualquier equipo técnico que ya tenga o planee tener Google Cloud en su stack y quiera construir integraciones robustas desde el principio. El costo de rediseñar una integración que ya está en producción y perdiendo eventos siempre es mayor que hacerlo bien desde el inicio.

¿Cómo aplica esto en tu empresa?

Si estás construyendo o manteniendo integraciones con Nylas para email o calendario, estas son las preguntas que vale la pena hacerse ahora:

  • ¿Tu webhook actual puede absorber un burst de miles de eventos en un minuto sin perder entregas? Si la respuesta no es un sí rotundo, Pub/Sub merece evaluación.
  • ¿Tienes infraestructura en Google Cloud o AWS? Si ya usas GCP o AWS, agregar un topic de Pub/Sub o SNS tiene un costo marginal muy bajo comparado con el valor que aporta.
  • ¿Diferentes equipos consumen diferentes tipos de notificaciones? La segmentación por topics elimina acoplamiento entre consumidores y simplifica el mantenimiento.
  • ¿Tienes un plan para eventos que fallan al procesarse? Sin dead-letter topic, esos eventos simplemente desaparecen. Con él, los puedes recuperar.

No es necesario migrar todo de golpe. Pub/Sub puede coexistir con tus webhooks actuales — los triggers de alto volumen se mueven al queue, los de bajo volumen pueden seguir en HTTP. La transición puede ser gradual.

Conclusión

Los webhooks HTTP son la solución más simple para notificaciones en tiempo real, y para muchos casos siguen siendo la opción correcta. Pero cuando el volumen crece, cuando la disponibilidad es crítica o cuando diferentes equipos necesitan consumir diferentes tipos de eventos de forma independiente, enrutar notificaciones a Google Pub/Sub o Amazon SNS es una decisión de arquitectura que ahorra muchos problemas en producción.

La barrera de entrada es baja: un topic en GCP, permisos de publicación para Nylas, y un comando en la CLI. Lo que obtienes a cambio — durabilidad, segmentación, dead-letter queues y backpressure natural — es infraestructura de mensajería de nivel enterprise sin tener que construirla desde cero.

Fuentes y Referencias

Dev.to — Route Nylas notifications to Google Pub/Sub

¿Construyes integraciones de email o calendario en tu plataforma empresarial?

En Consultoría-Ti ayudamos a equipos técnicos en Perú y LATAM a diseñar e implementar integraciones robustas sobre ERPs y plataformas empresariales, incluyendo arquitecturas de mensajería que escalan con el negocio. Si estás evaluando cómo hacer tu integración más confiable, conversemos.



✨ Contenido generado con ContentFlow — Consultoría-Ti

Compartir
Etiquetas
Feature Flags sin control: cómo evitar deuda técnica