In this section, we are going to learn how event driven architectures fits with the ADA, Lambda and
invocation types.
Let's start with learning.
Event driven architectures and event driven architectures.
Uses events to trigger and communicate between decoupled services and is common in modern applications
will be to microservices.
An event is a change in state or an update like an item being placed in a shopping cart on ecommerce
web application events can either carry the state, for example the item purchased, item price changed
and so on, or event can be an identifier.
For example, a notification that an order was placed or an order was shipped and so on.
So if you look at the image on the slide event, the ribbon architectures have three key components
event producers, event authors and event consumers.
Basically, a producer publish an event to the router which filters and pushes the events to the consumers.
Producers, services and consumer services are decoupled, which allows them to be scaled update and
deployed independently.
So this is the main benefit of event driven architecture.
So deploy independently for all parties.
Event producer, event, consumer and event structure can be scaled independently.
If you look at the benefits of the event driven architectures, we can say that scale and fail independently
with decoupling or services.
They are only aware of the event rather not each other.
This means that our services are interoperable, but if one service has a failure, the rest will keep
running.
The event router acts as an elastic buffer that will accommodate sorts in workloads, so another benefit
is developed with agility.
No longer need to write custom code to pull, filter and draw events.
The event router will automatically filter and push events to the consumers.
The router also removes the need of heavy coordination between producer and consumer services, speeding
up the development process so these provide the developing with agility.
Another benefit is audit with easy.
An event router acts as a centralized location to audit our application and define policies.
These policies can restrict who can publish and subscribe to a router and control which users and resources
have permission to access our data.
We can also include our events both in transit and rest.
So another benefit is cutting the cost.
Event driven architectures are push based, so everything happens on demand as the event presents itself
in a router.
This way you are not paying for continuous polling to check for an event.
This means less network bandwidth consumption, less CPU utilization and less idle time.
So this will come with a cutting to cost.
So if you look at the example on the slide image here, you can see the example architecture of the
event driven architecture for ecommerce application.
This architecture enables the site to react to change from a variety of resources during the time of
the peak demand without crushing the application or provisioning resources because every services communicate
with using the event backbone.
This provides event driven architecture and the compose services.
So let's see a list, even three services.
There are two main types of routers used in the event driven architectures, which is the event buses
and event topics.
So in a place, a place basically offers the messaging and ISP line in here and you can see the service
part services in here, which is the event sense and case.
So basically Amazon offers.
Event Bridge to build event buses.
And Amazon also offers SNS, which is the simple notification service to build event topics.
So let me explain one by one.
Amazon Event Update is recommended when you want to build an application that reacts to events from
the source.
Applications, Adobe Services and any custom applications event which use a predefined schema for events
and allows you to create rules that are applied across the entire event body to filter before pushing
the consumers.
Now let's talk about Amazon.
Since Amazon, RSNs is a recommended one, you want to build an application that works to high throughput
and low latency events published by other applications, microservices and so on.
So basically it is implementing fan out pattern with using the sense topics that is applying the event
schema with using the panel pattern.