Envío de correos en segundo plano con Node.js y SMTP

La aprobación de una campaña, un cambio de saldo o una alerta de seguridad de la cuenta no deberían obligar a una solicitud de Node.js a esperar a que responda un servidor de correo. Si el servidor de retransmisión tarda, la acción que ve el usuario puede agotar el tiempo de espera; si la aplicación reintenta la solicitud, podría enviar el mismo mensaje dos veces. Una configuración de producción más segura consiste en registrar la notificación junto con el evento de negocio y dejar que un proceso en segundo plano la envíe por SMTP. Este enfoque muestra cómo enviar correos en segundo plano con Node.js sin bloquear la solicitud.

Saca el correo electrónico del flujo de la solicitud

En una red publicitaria de criptomonedas, piensa en una campaña cuyo estado cambia de pendiente a aprobada. La aplicación debería confirmar ese cambio de estado cuanto antes, incluso si también debe enviar mensajes transaccionales y de marketing. No debería depender de que se complete una conexión SMTP antes de poder responder al anunciante.

Guarda un trabajo de correo electrónico en una tabla de la base de datos o en una cola duradera para correos transaccionales como parte de la misma transacción que el cambio de estado. Un proceso en segundo plano lee los trabajos pendientes y los envía a través del servidor de retransmisión. Así, la disponibilidad de la aplicación queda separada de la entrega del correo: una interrupción temporal del servidor puede retrasar la notificación sin deshacer una aprobación ni bloquear una acción del panel.

Si vas a incorporar un servidor de retransmisión SMTP con Node.js a un servicio existente, considera que el límite entre procesos es la principal decisión de diseño, no la biblioteca de correo. La plataforma de correo electrónico y mensajería puede proporcionar la conexión SMTP para los mensajes transaccionales, pero la aplicación sigue teniendo que decidir cuándo se crea un mensaje, cómo funcionan los reintentos y qué hacer cuando no se sabe con certeza si se entregó.

Asigna un único trabajo de notificación a cada evento de negocio

Crea el trabajo cuando se confirme el evento subyacente, en lugar de generarlo cada vez que se carga una página o un usuario reintenta una solicitud de API. Asígnale una clave de evento estable, como el identificador de la campaña junto con la transición de estado y la versión. Aplica una restricción de unicidad a esa clave para evitar que solicitudes duplicadas creen varios correos pendientes de aprobación.

Un registro de trabajo útil incluye el destinatario, un identificador de plantilla, los datos mínimos necesarios para generar el mensaje, el número de intentos, la hora del próximo intento y el estado. Evita guardar credenciales SMTP o información de cuenta innecesaria. Si la dirección del destinatario puede cambiar antes del envío, decide si el trabajo debe usar la dirección registrada en el momento del evento o la dirección verificada actual de la cuenta; deja esa política clara.

Vincula el correo generado a un cambio de estado real. El proceso en segundo plano no debería deducir que una campaña se aprobó a partir de datos obsoletos de la cola. Antes de enviar una alerta sensible, puede verificar la versión actual del evento o consultar el registro correspondiente. Así se evita informar al cliente de que se aprobó una campaña si se puso en pausa justo después.

Configura la conexión SMTP de Node.js en el proceso en segundo plano

Usa un cliente SMTP con mantenimiento activo, como Nodemailer, y lee los datos de conexión desde el entorno del proceso en segundo plano, en lugar de guardarlos en el código fuente. El siguiente ejemplo usa el puerto habitual para el envío; ajusta el puerto y la configuración de TLS para que coincidan con las credenciales de tu cuenta.

const nodemailer = require("nodemailer");

const port = Number(process.env.SMTP_PORT || 587);

const transporter = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port,
  secure: port === 465,
  requireTLS: port !== 465,
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS
  }
});

async function sendCampaignNotice(message) {
  return transporter.sendMail({
    from: process.env.MAIL_FROM,
    to: message.to,
    subject: message.subject,
    text: message.text,
    html: message.html
  });
}

Configura como remitente una dirección autorizada para tu sistema de envío y usa credenciales específicas para el proceso en segundo plano, en lugar de reutilizar las de una cuenta de administrador. No registres en los logs el mensaje completo, la contraseña ni la respuesta de autenticación. Una verificación al iniciar puede detectar una configuración no válida, pero no garantiza que un destinatario concreto acepte un mensaje posterior.

Reintenta los fallos temporales sin provocar una avalancha de correos

Clasifica los fallos en lugar de reintentar todos los errores con la misma frecuencia. Una estrategia de reintentos SMTP con Nodemailer debe distinguir los fallos temporales de conexión o las respuestas del servidor que indiquen que el servicio está ocupado, que se pueden reintentar con demoras cada vez mayores. Las credenciales no válidas, los destinatarios mal formados y otros errores persistentes de configuración o de dirección requieren investigación, no reintentos rápidos. Establece un número máximo de intentos y cambia el estado de los trabajos agotados para que un operador pueda revisarlos.

Usa un arrendamiento del proceso o un mecanismo equivalente para impedir que dos procesos de Node.js envíen el mismo trabajo pendiente a la vez. Cuando un proceso reclama un trabajo, registra el vencimiento del arrendamiento; si el proceso se detiene, otro podrá reclamarlo cuando venza. Fija el arrendamiento en una duración superior al tiempo de espera habitual del envío y amplíalo si la generación o la entrega del mensaje pueden tardar más.

SMTP no puede garantizar que la aplicación envíe un mensaje exactamente una vez. El servidor de retransmisión puede aceptar el mensaje y la conexión fallar antes de que el proceso reciba la confirmación. Reintentar en ese caso puede generar un duplicado; marcarlo como enviado antes de que se acepte puede hacer que se pierda. Usa claves de evento estables para evitar crear trabajos duplicados, limita los reintentos y acepta que este caso puntual de incertidumbre no siempre se puede resolver automáticamente.

Implementa el cambio de forma controlada

Antes de desviar el tráfico de producción, envía trabajos de prueba desde un entorno que no sea de producción y confirma que el proceso en segundo plano puede autenticarse, generar el contenido esperado y registrar los estados de éxito y error. Después, activa el proceso para un tipo de notificación de bajo riesgo. Compara el número de eventos de negocio, trabajos en cola y envíos completados; si la cola empieza a crecer, podrías detectar un problema del proceso o de configuración antes de pasar a las alertas críticas.

• Mantén el mismo esquema de mensajes en la aplicación web y el proceso en segundo plano durante el despliegue.
• Haz idempotente la creación de trabajos antes de ejecutar varias instancias del proceso.
• Supervisa la antigüedad de la cola, el número de reintentos, los fallos permanentes y el estado del proceso.
• Conserva una opción para volver a procesar manualmente los fallos revisados, en lugar de reenviar a ciegas todos los trabajos fallidos.

Cuando el proceso en segundo plano sea estable, elimina los envíos SMTP directos de los controladores de solicitudes para que estos mensajes sigan una única vía controlada. Si usas la plataforma de correo electrónico y mensajería como servidor de retransmisión, esta se encarga de la conexión SMTP; la cola, las reglas de eventos, la política de reintentos y la revisión operativa siguen siendo responsabilidad tuya. Este reparto es útil cuando los eventos de cuenta deben registrarse rápidamente incluso durante interrupciones breves del correo, pero no sustituye la supervisión ni una política clara para las notificaciones retrasadas.