Event Based Architecture

Event Based Architecture(EBA), also known as Event-driven architecture, is made up of event producers and event consumers connected via event routers.

• Event producer detects or senses an event and represents the event as a message. It does not know the consumer of the event, or the outcome of an event.
• After an event has been detected, it is transmitted from the event producer to the event consumers through event channels, where an event processing platform processes the event asynchronously. Event consumers need to be informed when an event has occurred. They might process the event or may only be impacted by it.
• The event processing platform will execute the correct response to an event and send the activity downstream to the right consumers. This downstream activity is where the outcome of an event is seen.

Pub/sub model
This is a messaging infrastructure based on subscriptions to an event stream. With this model, after an event occurs, or is published, it is sent to subscribers that need to be informed.

Event streaming model
With an event streaming model, events are written to a log. Event consumers don’t subscribe to an event stream. Instead, they can read from any part of the stream and can join the stream at any time.

When to use this architecture

Cross-account, cross-region data replication
You can use an event-driven architecture to coordinate systems between teams operating in and deploying across different regions and accounts. By using an event router to transfer data between systems, you can develop, scale, and deploy services independently from other teams.

Resource state monitoring and alerting
Rather than continuously checking on your resources, you can use an event-driven architecture to monitor and receive alerts on any anomalies, changes, and updates. These resources can include storage buckets, database tables, serverless functions, compute nodes, and more.

Fanout and parallel processing
If you have a lot of systems that need to operate in response to an event, you can use an event-driven architecture to fanout the event without having to write custom code to push to each consumer. The router will push the event to the systems, each of which can process the event in parallel with a different purpose.

Integration of heterogeneous systems
If you have systems running on different stacks, you can use an event-driven architecture to share information between them without coupling. The event router establishes indirection and interoperability among the systems, so they can exchange messages and data while remaining agnostic.

EBA - 5 Step Process

Step 1: Culture, Awareness, and Intent

• Are you ready, aware, and have the intent to implement event-driven architecture?
• You will need to think about which use cases can be candidates, look at them through the event-driven lens, and articulate a go-to approach to realize the benefits.
• Think real-time.
• Move away from a process based build mind set.

Step 2: Identify Real Time Candidates

• So how do you choose? Look for projects which need to be transformed for either pain removal (brittleness, performance, new functionality) or projects which will cause a medium-to-high business impact.
• It’s also important to bring in the stakeholders at this early stage because events are often business-driven, so not all your stakeholders are going to be technical.

Step 3: Build Your Eventing Foundation

• Identify the architecture and tooling. e.g. Solace , Confluent , AWS
• You need to decompose flows into microservices, putting in place a runtime fabric that lets the microservices talk to each other in a one-to-many, distributed fashion.
• Events can be described and catalogued, and have their relationships visualized.
• You’ll want to have an architecture that’s modular enough to meet all of your use cases, and flexible enough to receive data from everywhere that you have data deployed (on premises, private cloud, public cloud, etc.). This is where the eventing platform comes in with the event mesh runtime.

The following runtime and design time pieces are essential:

Event Broker: It is the runtime component for event routing in a pub sub, low latency and guaranteed delivery manner. Applications and microservices are decoupled from each other and communicate via the event broker. Events are published to the event broker via topics following a taxonomy and are correspondingly subscribed to by one or more applications or microservices, or analytics engines or data lakes. To avoid vendor lock in, an event broker should use open protocols and APIs.

Event Mesh: It is a network of event brokers that lets dynamically routes events between applications no matter where they are deployed – on premises or in any cloud or even at IoT edge locations.

Event Portal: It is the design and runtime view into your event mesh. An event portal gives architects an easy GUI-based tool to define and design events in a governed manner, and offers them for use by publishers and subscribers. Once you have defined events, microservices or applications can also be designed in the event portal and choose which events they will consume and produce by browsing and searching the event catalog.

Event Taxonomy: A solid taxonomy is probably the most important design investment you will make, so best not to take short cuts here. Having a good taxonomy will greatly help with event routing, and the conventions will become obvious to application developers.

Organizational Alignment: Event driven architecture starts small and grows, but over time, the organization needs to be evolved so that they can start thinking events. This requires some thought leadership to get buy-in. Think choreography, rather than orchestration. The API teams need to start thinking about event driven APIs, rather than just request/reply. Event Based Architecture – 5 Step Process.

Step 4: Pick Pilot Application and Event Catalog

• Event flow is a business process that’s translated to a technical process. The event flow is the way an event is generated, sent through your broker, and eventually consumed. Getting started with a pilot project is the best way to learn through experiment before you scale.
• With the pilot, as you identify events and the event flow, the event catalog will also automatically start taking shape. Whether you maintain the catalog in a simple spreadsheet or in an event portal, the initial event catalog also serves as a starting point of reusable events which applications in future will be able to consume off the event mesh.
  Pick a flow which can be your quick win.

Step 5: Decompose the Event Flow into Asynchronous, Event-Driven Microservices

• Start an event driven design by decomposing the business flow into event driven microservices, and identify events in the process.
• Decomposing an event flow into microservices reduces the total effort required to ingest event sources, as each microservice will handle a single aspect of the total event flow. New business logic can be built using microservices, while existing applications – SAP, Mainframe, Custom apps – can be event enabled with adapters.
• There are two ways to manage your microservices in your event flows: orchestration and choreography. With orchestration, your microservices work in a call-and response (request reply) fashion, and they’re tightly coupled, i.e. highly dependent on each other, tightly wired into each other. With event routing choreography, microservices are reactive (responding to events as they happen) and loosely coupled — which means that if one application fails, business services not dependent on it can keep on working while the issue is resolved.
• In this step, you’ll also need to identify which steps have to occur synchronously, and which ones can be asynchronous. Synchronous steps are the ones which need to happen for which the application or API invoking the flow is waiting for a response, or blocking, Asynchronous events can happen after the fact and often in parallel – such as logging, audit, writing to a data lake. In other words, applications which are fine with being “eventually consistent” can be dealt with asynchronously