Architettura basata su eventi
Nell’architettura basata su eventi, i componenti segnalano eventi ai quali altri componenti possono reagire indipendentemente.
Una modifica avvia altro lavoro
L'architettura basata su eventi organizza la collaborazione tramite eventi: notifiche di qualcosa che è già accaduto. I produttori li pubblicano; i consumatori interessati li elaborano attraverso un canale di eventi. In un esempio inventato, un'applicazione segnala l'approvazione di un preventivo. Pianificazione e reportistica possono reagire con compiti diversi.
Il produttore non deve chiamare direttamente ogni destinatario. Il disaccoppiamento richiede però significati chiari degli eventi, responsabilità e gestione degli errori. Messaggi duplicati o in ritardo e ordinamento possono essere rilevanti. L'evento pubblicato non dimostra che tutte le attività successive siano concluse. Per un flusso semplice, una chiamata diretta può comportare meno lavoro operativo.
Fonti
Termini correlati
- Eventual consistencyL’eventual consistency ammette stati dei dati temporaneamente diversi che devono convergere nelle condizioni previste.
- Broker di messaggiUn broker di messaggi accetta i messaggi e li inoltra ai destinatari secondo regole definite.
- Publish-subscribeIl modello publish-subscribe distribuisce i messaggi pubblicati ai sottoscrittori interessati senza contatti diretti con ogni destinatario.
- Transactional inboxUna transactional inbox usa registrazioni durature dei messaggi per proteggere l’elaborazione locale dalle consegne duplicate.
- Conferma dei messaggiLa conferma comunica al broker che una consegna è stata ricevuta o elaborata secondo la regola concordata.
- Jitter nei retryIl jitter varia casualmente le attese tra i retry per distribuire i nuovi tentativi e ridurre le richieste simultanee di più client.
Articoli sul tema
API & integrazione con ASES
ERP, CRM e negozio online collegati in modo pulito