Contesto

Il nostro gruppo crea ed è responsabile della gestione di più app per un'istituzione più grande. Siamo in procinto di suddividere i nostri monoliti in microservizi riutilizzabili (evviva!). Quando ci siamo alzati alle notifiche (principalmente notifiche via email) siamo rimasti bloccati. I nostri utenti consumano più applicazioni, e ogni servizio può avere decine di punti trigger che sparerebbero una notifica ad altri utenti. Adottiamo la filosofia secondo la quale ogni microservizio dovrebbe gestire le proprie notifiche o tutte le notifiche dovrebbero appartenere a un servizio per se stesse e fare affidamento sui trigger di database?

Sto cercando articoli o forse qualche consiglio di esperienza in quanto è qualcosa che non possiamo davvero permetterci di sbagliare.

L'argomento per le notifiche nel servizio

I microservizi dovrebbero essere autonomi. Ognuno è responsabile del proprio stato, del proprio modello e dovrebbe [il più possibile] non essere dipendente da un altro servizio per funzionare. Le notifiche sono una caratteristica essenziale per molti servizi. A che serve un servizio di chat se devi aprirlo ogni volta per verificare le nuove chat? Per quanto riguarda le azioni, il microservizio dovrebbe attivare le notifiche, sia direttamente che accedendo con un servizio di consegna della posta. Questo aiuta anche con la mitigazione e l'ulteriore sviluppo. Durante l'iterazione sul servizio, lo sviluppatore è sempre a conoscenza di quali notifiche possono essere inviate a seconda delle modifiche allo stato dell'applicazione.

Il caso per i trigger del database

Considerando il volume di notifiche inviate, è meglio averle centralizzate. Eventuali aggiornamenti, aggiunte o cancellazioni di notifiche dovrebbero avvenire in un unico luogo. Inoltre, le notifiche inviate dal controller (o azioni in flusso) sono rischiose, poiché è possibile che dopo l'azione venga eseguita, l'operazione DML non riesce. Ciò comporterebbe un utente che riceve una notifica che non è sincronizzata con la fonte della verità: il database. Avendo il servizio di notifica basato esclusivamente sui trigger nel database, esso mantiene anche l'incapsulamento del servizio. Il servizio di notifica non si cura del servizio che ha aggiornato il modello, solo che il modello ha effettivamente aggiornato. Un altro rischio è rappresentato da più applicazioni che operano sulla stessa tabella (mentre questa può sembrare una cattiva architettura, potresti avere un'app di amministrazione e un'app utente). Se ci sono più servizi che aggiornano una tabella, è possibile che più notifiche vengano inviate agli utenti con voci in conflitto. Centralizzandolo, sei in grado di assicurarti che solo una singola notifica si spenga (forse limitando quante notifiche si attivano in un singolo intervallo, quindi notificando solo l'ultima delle modifiche).

Domanda

Siamo responsabili di alcuni microservizi che hanno decine di notifiche. Il nostro team sta crescendo abbastanza rapidamente, e la mia paura è che avremo notifiche ovunque. Gli sviluppatori potrebbero accidentalmente fare uno switch in codice, senza rendersi conto che questo farà scattare un sacco di notifiche ad un utente povero. Ciò che è importante per me è la coerenza attraverso l'org.

Spero di avere qualche consiglio sui compromessi tra le due architetture sopra descritte - notifiche dalla logica dell'applicazione o da trigger di database.

Grazie mille, tanto per il tuo aiuto e considerazione!