Skip to main content
Traducción. Autoritativo: ../../../modules/messaging/prd.md.
messaging es cómo cualquier cosa de la suite alcanza a una persona. Decide si un mensaje puede enviarse, por qué canal, lo renderiza, lo encola en el carril correcto, lo entrega por un proveedor y registra qué pasó con él — todo rastreable hasta el evento que lo causó.

Para quién es

El problema hoy

Dos problemas, y uno es nuestro. El del tenant es que las herramientas de engagement tratan consentimiento, supresión y quiet hours como configuraciones de campaña en vez de compuertas. Un mensaje sale a alguien que se dio de baja la semana pasada porque la lista se exportó antes, y eso es un reclamo ante un regulador, no un bug. El nuestro es un número duro de la investigación: el rate limit de Resend es por team, a través de todas las API keys — todos los tenants comparten un presupuesto. Un blast de marketing puede dejar sin OTPs ni comprobantes a todos los demás. Ese hallazgo es por qué existe ADR-015 y por qué los carriles duales están en F1a y no como preocupación de escalamiento. Una plataforma donde la campaña de un cliente rompe el login de otro no es multi-tenant, diga lo que diga la base de datos.

Qué hace (normativo)

  • Resuelve si y dónde enviar, con una función pura en cascada sobre cuatro niveles de configuración más las compuertas del propio destinatario (ADR-019).
  • Renderiza plantillas con variables validadas contra las definiciones de atributos reales.
  • Encola en dos carriles por canal — el transaccional siempre gana al de marketing (ADR-015).
  • Entrega por adaptadores de canal tras un puerto, de modo que un canal nuevo es un adaptador y no una cirugía.
  • Registra cada envío desde queued hasta opened, unido por correlation_id al evento de dominio que lo causó.
  • Mantiene supresiones automáticas desde rebotes duros y quejas, verificadas en cada envío.
  • Da al member un centro de preferencias por canal y por categoría.
  • Corre campañas: blasts a un segmento, y automatizaciones permanentes por evento, propiedad de fecha o entrada a segmento.

Lo que NO hace (normativo)

  • No es un diseñador de plantillas. Las plantillas son componentes React Email en el repositorio, versionados como código. Un editor visual es superficie de producto que quizá queramos después; no es lo que hace que los mensajes salgan.
  • No es una consultoría de deliverability. Automatizamos SPF/DKIM y el warm-up, y exponemos tasas de rebote y queja. La reputación es en última instancia el comportamiento de envío del tenant.
  • No es una bandeja de entrada. Las respuestas van a la dirección del propio tenant.
  • Sin contenido de mensajes en analítica. Contamos envíos, aperturas y clics. Lo que se escribió queda con el registro del envío y se borra con el titular al suprimirse.
  • Ni WhatsApp ni Live Activities en F1. Ambos son F2 y necesitan vendor y ADR (DEC-E1).

Éxito

Modelo comercial

Los mensajes son una métrica medida con precios unitarios publicados por canal (ADR-016) — email y push nos cuestan distinto y se cobran por separado. El enforcement es duro al 110% (DEC-G2), porque un envío sin límite es una cuenta sin límite para nosotros. Una capacidad es add-on: un dominio de envío propio (DEC-F4). El default es un subdominio compartido, que funciona; un tenant que quiere correo desde su propio dominio paga la configuración y el aislamiento de reputación que trae.

Fases

Cumplimiento y riesgo

Este módulo es donde una falla de consentimiento se vuelve un evento regulatorio, así que el consentimiento no se consulta: es una compuerta que no se puede saltar.
  • Transaccional nunca es opt-out (DEC-E3), y marketing nunca sale sin otorgamiento activo. No hay configuración de tenant que cambie ninguna de las dos.
  • Las supresiones sobreviven a la supresión de datos como identificador hasheado sin perfil. Borrarlas permitiría volver a escribirle a una persona borrada.
  • El contenido del mensaje es dato personal. Se borra con el titular; solo quedan conteos.
El riesgo operativo principal es la reputación del proveedor: la mala lista de un tenant daña el dominio compartido de todos. Mitigado con límites de warm-up, supresión automática, umbrales de rebote y queja que pausan a un remitente, y dominios propios para quienes envían volumen.

Dependencias

core para contactos, consentimiento y segmentos — dura y de una sola dirección. Resend, FCM, Upstash. QueuePort y NotificationChannelPort (enmienda A1). Todos los demás módulos dependen de este, y lo alcanzan solo por eventos de dominio.

Preguntas abiertas

Changelog