All language subtitles for 009-Event Based Communication-git.ir

In this video we're going to take a look at communication between services using an asynchronous communication

style.

We're going to take a look at two different ways of using async communication.

The first way that we're gonna look at in this video in particular is not going to be super great.

It's going to have some really big downsides and in the next video we're going to take a look at the

second way of using asynchronous communication.

So let's get to it in this video.

Method number one not so great but you need to know it anyways.

Ok.

So the general idea between asynchronous communication is that we're going to introduce something into

our entire application that is accessible from all these different services refer to this thing as an

event bus.

The goal of this event bus is to handle little notifications or events being emitted from our different

services these different notifications or events are like little objects you can imagine like little

notes that describe something that has happened or something that needs to happen inside of our overall

application each service is going to connect to this event bus once it is connected.

Each service can either emit events or receive events from the event bus.

Now one thing you might notice right away is that we've got all of our services wired up to one common

thing right here which means that we've got a single point of failure.

So whenever we deploy an event bus we usually go through a decent amount of effort to make sure that

this thing is relatively resilient and it's not going to crash all the time and therefore restrict communication

between our services.

Let's start to walk through an actual example of how we can use an event bus and he might events to

solve this issue around service D.

OK.

So we're going to imagine that service D receives a request asking to see all the products have been

ordered by a particular user service D needs information from its services A B and C to complete this

request.

So the first thing that service t will do is emit an event.

So this is an event right here and event might have some type that describes what kind of event is occurring

and it might have some data or contextual information associated with it as well.

So in this case we might imagine that the type is something like user query and the data might be the

idea of the user that we want to look up as a reminder.

We're trying to make sure that whenever someone asks for information about a particular user we're gonna

make sure that that user actually exists first.

So this event would flow on over to this event bus the event bus can automatically handle incoming events

and route them off to different services that might be able to handle that event.

So in this case we might be able to configure our event bus to send a copy of this event over to service

a.

And so we can imagine that this event is going to flow over like so then inside of service a we would

have some code to be executed any time this event comes in.

So service they might see this event come in it might say oh someone's trying to look up some information

about a user so service they could then look up information about the user with I.D. number one and

then to respond or get some information back over to service D service a could emit a new event so it

could emit any event over to the event bus and maybe it would be an event with a type of something like

user query result and then the data could be the actual information about this user so maybe their I.D.

and a name of Jill and whatever else.

So this event would flow into our event buzz and the event plus we could configure it so that it will

send an event of type user query results automatically back over to service.

So we'll go back over to a service D and we'll have some code inside of service t to receive an event

of type user quick results and do some processing on it.

You can then kind of imagine that we'd repeat the same exact process to take a look at all the different

orders that this user has created and then retrieve details about all the different products associate

with those orders as well from service B.

That is one possible way of doing asynchronous communication using events.

Now I want to repeat again right away that you're not really going to see this used terribly often in

the wild and there's a very good reason for that.

The reason is it basically is shares all the downsides of synchronous communication but it has additional

downsides associated with it.

So first off I would say that this is conceptually not super easy to understand.

Service D doesn't need a database.

Yeah that's still true.

But with this style of asynchronous communication we still have a dependency between services if any

of these events fails to be processed the overall request is going to fail or probably time out.

We still can only get a request or response back to the original request as quickly as the slowest event.

And once again we can easily be introducing a web of different events being emitted.

So this style of asynchronous communication not the best thing in the world.

But again you still need to know that this exists.

So that really just leaves us with one last option.

Remember just a moment ago I told you that there were two possibilities of using asynchronous communication

to solve the issue that we're in right now.

Just take another pause right here.

We'll come back the next video we'll take a look at the second form of asynchronous communication that

we're going to use.