Event-driven Architecture
You know that one of the best practices of modern application components is to decouple application components and make them modular so that you can plug and play those components while packaging solutions as you want.
An event-driven architecture uses events to trigger and communicate between these decoupled services. It is quite common to make use of event-driven architecture in building modern applications.
An event is a change in state, or an update, just like an item being seen, an web URL being clicked, shopping items added to the shopping cart, opening a mobile application, tapping on a button.
Events can carry the state (page URL being viewed, the user Id, the item viewed, price of the item added to cart, location of the app user, wait time of the user). Events can also be identifiers (a notification that a service is not available, inventory is below a level).
Event-driven architecture has three key components: event producers, event routers, event consumers. The event producer publishes an event to the router. Router filter, transforms the event. Router pushes the event to the consumer or consumer pulls the event itself
Thus the producer & consumer components are completely decoupled, and those components can be scaled, updated, and deployed independently.
Some interesting facts…
The good news is that there are a number of messaging middleware available that has routing mechanism built in so that we don’t need to create event routing mechanisms from scratch. We configure the message queues, or message topics on the middleware and we are ready to go.
If you have solution components – event publisher, event consumer – running on different technology stacks, you can use an event-driven architecture to establish sharing of information between them. The messaging middleware ensures indirection and interoperability in the architecture, so that those solution components can exchange messages and data while remaining on different technology stack.
If you have a multiple solution components that need to operate in response to the same event generated, you can use an event-driven architecture to fanout the event without having to write custom code to push to each event consumer. The router will push the event to the systems, each of which can process the event independently, in parallel and for a different purpose.
What you need to know?
For fast-moving engineering development of modern solutions, event-driven architecture is critical. While adopting an event-driven architecture paradigm, you must rethink about your application design. To implement event-driven architecture, consider the following point carefully:
- How will you make application component handle the asynchronous nature of events routed?
- How will you size the capacity of routing/messaging middleware?
- How will you track event flow dynamically?
- How durable is your event architecture? Will it support the business use case in terms of reliability and guaranteed delivery?
- In case there is a need to rebuild state from a series of events, how will you do it using event-oriented architecture?