envío de correos electrónicos en aplicaciones web

Question

estoy en busca de algunas opiniones aquí, yo estoy construyendo una aplicación web que tiene la funcionalidad bastante estándar de:

1. Registro para una cuenta rellenando un formulario y presentarlo .
2. recibirá un correo electrónico con un enlace código de confirmación
3. Haga clic en el enlace para confirmar la nueva cuenta e ingrese

Al enviar mensajes de correo electrónico desde la aplicación web, es a menudo (por lo general) el caso de que no lo hará habrá algún cambio en la capa de persistencia. Por ejemplo:

1. Un nuevo usuario se registra para una cuenta en su sitio - el nuevo usuario se crea en la base de datos y se envía un correo a ellos con un enlace de confirmación
2. Un usuario asigna un error o un problema de Alguien más: el problema se actualiza y se envían las notificaciones por correo electrónico.

Cómo enviar estos correos electrónicos puede ser crítico para el éxito de su aplicación. La forma en que los envíe depende de cuán importante es que el destinatario previsto reciba el correo electrónico.

nos ocuparemos de las cuatro estrategias siguientes en relación con el caso en el que el servidor de correo está abajo, usando el ejemplo 1.

TRANSACTIONAL & SÍNCRONOS El envío del correo electrónico falla y se muestra al usuario un error mensaje que dice que su cuenta no pudo ser creada. La aplicación parecerá lenta y no responderá mientras la aplicación espera el tiempo de espera de la conexión. La cuenta no se crea en la base de datos porque la transacción se revierte.

TRANSACTIONAL & ASÍNCRONO La definición transaccional se refiere aquí a enviar el correo electrónico a una cola JMS o guardarla en una tabla de base de datos para otro proceso en segundo plano para recoger y enviar.

La cuenta de usuario se crea en la base de datos, el correo electrónico se envía a una cola JMS para su posterior procesamiento. La transacción es exitosa y comprometida. Al usuario se le muestra un mensaje que dice que su cuenta fue creada y para verificar su correo electrónico para un enlace de confirmación. En este caso, es posible que el correo electrónico nunca se envíe debido a algún otro error, sin embargo, se le informa al usuario que se le envió el correo electrónico. Puede haber algún retraso en enviar el correo electrónico al usuario si se debe llamar al soporte de la aplicación para diagnosticar el problema del correo electrónico.

NO TRANSACCIONAL & SYNCHRONOUS El usuario se crea en la base de datos, pero la aplicación obtiene un error de tiempo de espera cuando intenta enviar el correo electrónico con el enlace de confirmación. El usuario muestra un mensaje de error que dice que hubo un error. La aplicación es lenta y no responde mientras espera el tiempo de espera de conexión

Cuando el servidor de correo vuelve a la vida y el usuario intenta registrarse nuevamente, se les informa que su cuenta ya existe pero no se ha confirmado y se les da la opción de tener el correo electrónico reenviado a ellos.

no transaccionales & ASÍNCRONO La única diferencia entre esto y transaccional & asíncrona es que si hay un error al enviar el correo electrónico a la cola JMS o guardarla en la base de datos de error, la cuenta de usuario todavía se crea pero el correo electrónico es nunca enviado hasta que el usuario intente registrarse nuevamente.

Lo que me gustaría saber es qué han hecho otras personas aquí? ¿Me puede recomendar otras soluciones además de las 4 que he mencionado anteriormente? ¿Cuál es una forma razonable de abordar este problema? No quiero sobre-diseñar un sistema que tenga que ver con la (rara vez) situación en la que mi servidor de correo se cae.

Lo más simple es codificarlo sincrónicamente, pero ¿hay algún otro inconveniente para este enfoque? Supongo que me pregunto si hay una mejor práctica, no pude encontrar mucho por ahí buscando en Google.

Answer 1

Mis 2 centavos:

1. Una vez que tenga un usuario firmar para arriba, nunca hacer retroceder el registro si falla el envío del correo electrónico. Por simples motivos de negocios: es posible que no regresen o se vuelvan a registrar si no funciona en el primer intento. Más bien tolera un registro incompleto y molesta al usuario para que confirme su dirección de correo electrónico tan pronto como sea posible.

2. En la mayoría de los casos, al enviar un correo electrónico no funciona, su aplicación no recibirá comentarios inmediatos: las direcciones de correo electrónico inexistentes en servidores válidos enviarán un mensaje "no entregado" con algún retraso; si el correo es devorado por un filtro de correo no deseado, no obtendrá ningún comentario; en otros escenarios, puede tomar varios minutos (lista gris) hasta varios días (servidor de correo temporalmente inactivo) para que se entregue un correo electrónico. Un enfoque sincrónico a la espera de la entrega del correo está condenado a IMO. Incluso una falla inmediata (porque el usuario ingresó una dirección obviamente falsa) debería nunca dar como resultado que el registro se retrotraiga.

Lo que me gustaría hacer es, hacer que la creación de cuentas lo más fácil posible, permitir el acceso del usuario a la cuenta antes se confirma, y ​​luego darle la lata a la mierda de ellos para confirmar su correo electrónico (si es necesario, limite el acceso a ciertas áreas hasta confirmación). Sin embargo, evitaría la creación de una segunda cuenta con el mismo correo electrónico para evitar el desorden.

Asegúrese de permitir cambiar la dirección de correo electrónico, incluso si la dirección anterior no se ha confirmado aún, y permitir al usuario volver a solicitar el mensaje de confirmación a una dirección diferente.