Arquitectura del sistema de alertas

Me gustaría crear un sistema que maneje los mensajes de alerta de varios programas y pueda procesar esas alertas a los consumidores con poco viento por correo electrónico. Todo esto estaría contenido en una red interna.

Creo que quiero que la arquitectura básica se vea así:

La principal preocupación que tengo actualmente es el bit "Manejador de mensajes", que es lo que será mi "tipo de API". Quiero que todos los componentes de este sistema envíen datos a la API, que maneja todas las escrituras a la base de datos. Creo que este enfoque es más fácil porque simplifica la seguridad y me permite contener muchas de las consultas DB más complicadas en un solo programa.

La preocupación es que quiero que esto sea independiente del lenguaje, lo que significa que cualquier código debería poder enviar mensajes a mi controlador, que los interpretará. Espero hacer esto a través de archivos planos JSON, o mediante llamadas REST al programa (dando flexibilidad a las aplicaciones posteriores).

Mi pregunta es-

¿Debería molestarme con el controlador de mensajes, o agregaría simplicidad para permitir el acceso directo a la base de datos a las aplicaciones posteriores, así como a los otros dos componentes (Consola de administración y Administrador de alertas)?

De esa forma, pueden insertar cualquier alerta que deseen, siempre y cuando INSERT en la / s tabla / s de la base de datos sea válida.

No soy un diseñador de software de profesión, así que discúlpeme, solo quiero un proyecto para hacer en mi tiempo libre.

¿Has examinado AMQP (Protocolo avanzado de colas de mensajes: https://www.rabbitmq.com/protocol.html )?

RabbitMQ es una herramienta increíble para algo como esto, creo (también hay otros, MSMQ, servicios Azure / AWS, etc.). No solo obtiene un controlador de mensajes agnóstico de un idioma (simplemente "envíe el mensaje al servidor de mensajes con datos json"), sino que desconecta el procesamiento de mensajes aguas abajo y lo aisla bien. Ejecute un servicio de mensajes que procese los mensajes entrantes de las colas que necesita y escupe sus notificaciones.

Una de las razones por las que realmente me gusta usar AMQP es que comienzas como si ahora estuvieras con alguna solución casera, pero después de un tiempo debes darte cuenta de que debes manejar los mensajes de manera ligeramente diferente dependiendo del tipo, a quién debe dirigirse, etc. , así que terminas esencialmente construyendo tu propia implementación AMQP de todos modos.

¿Qué haces si un mensaje debe ir a 5 destinatarios diferentes? ¿Qué sucede si tiene un mensaje que debe rotarse en varios procesadores (piense en tareas de ejecución prolongada y tenga un número X de procesadores simultáneos, en los que puede hacer un round-robin de mensajes de un tipo específico). ¿Qué pasa si el mensaje debe ir a una persona, pero si no está disponible / en línea, debe ir a otra? El AMQP ya maneja todo esto (¡bastante bien!), Con una categorización muy agradable, colas, canales, persistencia duradera, todo tipo de características.

Aquí hay una descripción básica de los escenarios que puede manejar (tenga en cuenta que esto no es específico de RabbitMQ: es una cuestión de AMQP, pero RabbitMQ lo explica bien) - https://www.rabbitmq.com/getstarted.html

Pregunta muy bien enmarcada!

Entonces, todas las decisiones arquitectónicas implican compensaciones. Si tiene curiosidad por una discusión de compensaciones, quizás edite su pregunta en esa dirección. En cambio, dado que la pregunta solo pide una posición, tomaré el lado de argumentar a favor del MessageHandler. Iré un paso más allá para sugerir NO incluir una base de datos, al menos no una base de datos SQL, al menos no comenzar. Simplemente haga que MessageHandler guarde JSON en el sistema de archivos, diga un directorio por hora de alertas recibidas (dependiendo del volumen, por supuesto) y tenga la API cuando el Administrador de alertas lo consulte, solo recorre los últimos 2 directorios de alertas para decidir qué correos electrónicos entregar (dependiendo de la prioridad, por supuesto).

Hay un montón de cosas buenas para analizar en este problema, y ​​mantener una base de datos fuera de la imagen en las primeras etapas eliminará mucho ruido incidental y la resolución innecesaria de problemas. Por supuesto, quizás tenga un amor oculto por crear modelos de datos relacionales y sueñe con escribir SQL. En ese caso, esta respuesta es totalmente incorrecta. Pero en términos generales, incluso las bases de datos más ágiles son plataformas de aplicaciones terribles, y solo se incluyen en los sistemas porque son especialistas en durabilidad y consulta indexada.

¡Buena suerte!