Arquitectura dirigida per esdeveniments

Què és l'arquitectura dirigida per esdeveniments?

L'arquitectura dirigida per esdeveniments és una manera de construir sistemes on els components es comuniquen produint i reaccionant a esdeveniments en lloc de cridar-se entre si directament. Un servei fa alguna cosa, anuncia que ha passat i segueix endavant. Altres serveis escolten aquest anunci i actuen en conseqüència. El productor mai sap ni li importa qui està escoltant, cosa que manté les parts feblement acoblades.

Compara-ho amb el model petició-resposta que fan servir la majoria de les APIs, on un servei crida un altre i espera una resposta. Funciona, però lliga els serveis amb força entre si. Si el servei cridat va lent o està caigut, el que crida es queda encallat. En un muntatge dirigit per esdeveniments, un servei de comandes pot publicar un esdeveniment "comanda feta", i els serveis de facturació, inventari i correu reaccionen cadascun al seu ritme. Quan un client fa el checkout d'una botiga online, aquest únic esdeveniment pot disparar un càrrec de pagament, una rebaixa d'estoc i un email de confirmació sense que el flux de checkout esperi cap d'ells.

El compromís és la complexitat. Un flux que era una línia recta es converteix en una xarxa de reaccions, més difícil de rastrejar i depurar. També has de pensar en l'ordre, en els esdeveniments duplicats i en què passa quan un consumidor falla. La recompensa són sistemes que escalen de manera independent i absorbeixen la càrrega, ja que els esdeveniments es poden encuar i processar quan els consumidors estan a punt en lloc de desbordar una cadena de crides síncrona.

Arquitectura dirigida per esdeveniments a Dallonses

Fem servir patrons dirigits per esdeveniments on es guanyen el seu lloc, normalment quan un sistema té diverses tasques que poden passar de manera independent després d'un disparador. Un client de retail necessitava que el checkout seguís ràpid mentre un munt creixent de feina posterior se li anava acumulant al darrere: comprovacions de frau, fulfilment, punts de fidelitat, analítica. Vam moure aquesta feina darrere d'esdeveniments perquè el camí de cara al client seguís àgil i cada servei posterior pogués escalar i fallar pel seu compte sense arrossegar la resta.

No és la resposta correcta per a tot projecte, i som honestos amb això, perquè el cost de depuració és real. Quan sí que encaixa, la nostra feina d'integració d'API i de plataformes s'hi recolza per connectar sistemes que no haurien d'estar esperant-se els uns als altres. Dissenyem els esdeveniments, els contractes i la gestió d'errors per endavant, perquè l'acoblament feble segueixi sent un actiu en lloc de convertir-se en un sistema que ningú pot seguir.

Tens sistemes que haurien de reaccionar entre si sense fer cua? Dissenyem el flux.

Parlem d'arquitectura