What is Event-driven Architecture?

EDA is a higher level application design paradigm that defines the way parts of your application interact with each other and with external applications. Interactions are defined in terms of events, event emitters, event managers, and event consumers.

• Events — are simply actions that took place (e.g. button_clicked, email_sent, or tree_fell_in_the_forest). They don’t care whether anyone was around to hear about them; they simply happen.
• Event emitters —announce to the world when events take place (e.g. the resounding boom of a tree hitting the forest floor). They have no knowledge of what the world might do with this information.
• Event managers — listen out for events in the world and inform interested event consumers (e.g. the Forest Ranger, who heard the ‘boom’ of a tree falling).
• Event consumers — subscribe to some event manager and perform some series of actions upon notification of an event’s occurrence (e.g. the logging crew who collect fallen trees when notified by the Rangers).

As an example with more depth, we can examine the relationships between employers, candidates, and recruiters.

• Candidates broadcast qualification and interest information to the world.
• Recruiters are constantly monitoring the world for potential candidates, processing information about them, and notifying appropriate employers in the event that a relevant candidate is found.
• Employers are subscribed to recruiters, and they expect to receive notifications when relevant candidates are discovered.

Here, the candidates are event emitters, the recruiters are event managers, and the employers are event consumers. The events emitted by candidates are each simply a broadcast of qualification and interest. The processing performed by the recruiter might consist of parsing the information provided, connecting with the candidate on LinkedIn, and determining whether there are any interested consumers to notify. The action performed by the employers may be the triggering of some series of vetting and hiring events in a separate system that governs their hiring process.

How is Event-driven Architecture the same as Message-driven Architecture?

Both patterns look roughly the same with the exception of distinction between message and event. It is sometimes the case that a message has an intended recipient, whereas this is never the case for an event.

How is Event-driven Architecture different from Event-driven Programming?

EDP uses EDA to govern the flow of a program. It is a good fit for programs driven by user input. As an example, we can analyze how interactive web applications use the EDP paradigm with JavaScript. When a user clicks on an element, an event is emitted (element_clicked), and some information is passed along (elementId). JavaScript’s event loop hears that event and checks for interested event consumers (onClick event listeners). Events are emitted even if no event listeners are registered.

More coming soon!