1
00:00:01,450 --> 00:00:06,400
In this video we're going to take a look at communication between services using an asynchronous communication

2
00:00:06,400 --> 00:00:07,370
style.

3
00:00:07,390 --> 00:00:11,890
We're going to take a look at two different ways of using async communication.

4
00:00:11,950 --> 00:00:16,390
The first way that we're gonna look at in this video in particular is not going to be super great.

5
00:00:16,390 --> 00:00:20,200
It's going to have some really big downsides and in the next video we're going to take a look at the

6
00:00:20,200 --> 00:00:23,080
second way of using asynchronous communication.

7
00:00:23,140 --> 00:00:25,180
So let's get to it in this video.

8
00:00:25,180 --> 00:00:29,050
Method number one not so great but you need to know it anyways.

9
00:00:29,050 --> 00:00:29,320
Ok.

10
00:00:29,350 --> 00:00:34,180
So the general idea between asynchronous communication is that we're going to introduce something into

11
00:00:34,180 --> 00:00:39,550
our entire application that is accessible from all these different services refer to this thing as an

12
00:00:39,550 --> 00:00:41,040
event bus.

13
00:00:41,320 --> 00:00:47,290
The goal of this event bus is to handle little notifications or events being emitted from our different

14
00:00:47,290 --> 00:00:53,830
services these different notifications or events are like little objects you can imagine like little

15
00:00:53,830 --> 00:00:59,530
notes that describe something that has happened or something that needs to happen inside of our overall

16
00:00:59,560 --> 00:01:06,250
application each service is going to connect to this event bus once it is connected.

17
00:01:06,310 --> 00:01:11,400
Each service can either emit events or receive events from the event bus.

18
00:01:11,420 --> 00:01:15,700
Now one thing you might notice right away is that we've got all of our services wired up to one common

19
00:01:15,700 --> 00:01:19,300
thing right here which means that we've got a single point of failure.

20
00:01:19,340 --> 00:01:23,560
So whenever we deploy an event bus we usually go through a decent amount of effort to make sure that

21
00:01:23,560 --> 00:01:29,170
this thing is relatively resilient and it's not going to crash all the time and therefore restrict communication

22
00:01:29,170 --> 00:01:30,580
between our services.

23
00:01:30,850 --> 00:01:35,740
Let's start to walk through an actual example of how we can use an event bus and he might events to

24
00:01:35,740 --> 00:01:38,920
solve this issue around service D.

25
00:01:39,040 --> 00:01:39,500
OK.

26
00:01:39,560 --> 00:01:44,420
So we're going to imagine that service D receives a request asking to see all the products have been

27
00:01:44,420 --> 00:01:51,020
ordered by a particular user service D needs information from its services A B and C to complete this

28
00:01:51,020 --> 00:01:51,900
request.

29
00:01:51,920 --> 00:01:55,650
So the first thing that service t will do is emit an event.

30
00:01:56,270 --> 00:02:02,360
So this is an event right here and event might have some type that describes what kind of event is occurring

31
00:02:02,870 --> 00:02:07,430
and it might have some data or contextual information associated with it as well.

32
00:02:07,430 --> 00:02:11,960
So in this case we might imagine that the type is something like user query and the data might be the

33
00:02:11,960 --> 00:02:15,060
idea of the user that we want to look up as a reminder.

34
00:02:15,080 --> 00:02:19,430
We're trying to make sure that whenever someone asks for information about a particular user we're gonna

35
00:02:19,430 --> 00:02:21,550
make sure that that user actually exists first.

36
00:02:22,970 --> 00:02:29,570
So this event would flow on over to this event bus the event bus can automatically handle incoming events

37
00:02:29,750 --> 00:02:34,460
and route them off to different services that might be able to handle that event.

38
00:02:34,460 --> 00:02:40,850
So in this case we might be able to configure our event bus to send a copy of this event over to service

39
00:02:40,910 --> 00:02:41,540
a.

40
00:02:41,780 --> 00:02:47,710
And so we can imagine that this event is going to flow over like so then inside of service a we would

41
00:02:47,710 --> 00:02:51,530
have some code to be executed any time this event comes in.

42
00:02:51,750 --> 00:02:56,380
So service they might see this event come in it might say oh someone's trying to look up some information

43
00:02:56,380 --> 00:03:01,720
about a user so service they could then look up information about the user with I.D. number one and

44
00:03:01,720 --> 00:03:09,430
then to respond or get some information back over to service D service a could emit a new event so it

45
00:03:09,430 --> 00:03:16,610
could emit any event over to the event bus and maybe it would be an event with a type of something like

46
00:03:16,880 --> 00:03:23,710
user query result and then the data could be the actual information about this user so maybe their I.D.

47
00:03:23,870 --> 00:03:27,040
and a name of Jill and whatever else.

48
00:03:27,160 --> 00:03:33,200
So this event would flow into our event buzz and the event plus we could configure it so that it will

49
00:03:33,200 --> 00:03:38,430
send an event of type user query results automatically back over to service.

50
00:03:38,960 --> 00:03:45,980
So we'll go back over to a service D and we'll have some code inside of service t to receive an event

51
00:03:46,040 --> 00:03:49,810
of type user quick results and do some processing on it.

52
00:03:50,150 --> 00:03:54,410
You can then kind of imagine that we'd repeat the same exact process to take a look at all the different

53
00:03:54,470 --> 00:03:59,750
orders that this user has created and then retrieve details about all the different products associate

54
00:03:59,750 --> 00:04:02,760
with those orders as well from service B.

55
00:04:02,840 --> 00:04:07,660
That is one possible way of doing asynchronous communication using events.

56
00:04:07,670 --> 00:04:12,560
Now I want to repeat again right away that you're not really going to see this used terribly often in

57
00:04:12,560 --> 00:04:15,540
the wild and there's a very good reason for that.

58
00:04:15,610 --> 00:04:21,920
The reason is it basically is shares all the downsides of synchronous communication but it has additional

59
00:04:21,920 --> 00:04:24,150
downsides associated with it.

60
00:04:24,150 --> 00:04:27,760
So first off I would say that this is conceptually not super easy to understand.

61
00:04:29,170 --> 00:04:30,580
Service D doesn't need a database.

62
00:04:30,600 --> 00:04:31,860
Yeah that's still true.

63
00:04:32,110 --> 00:04:37,810
But with this style of asynchronous communication we still have a dependency between services if any

64
00:04:37,810 --> 00:04:43,020
of these events fails to be processed the overall request is going to fail or probably time out.

65
00:04:43,240 --> 00:04:48,940
We still can only get a request or response back to the original request as quickly as the slowest event.

66
00:04:49,480 --> 00:04:54,370
And once again we can easily be introducing a web of different events being emitted.

67
00:04:54,370 --> 00:04:58,560
So this style of asynchronous communication not the best thing in the world.

68
00:04:58,570 --> 00:05:02,220
But again you still need to know that this exists.

69
00:05:02,400 --> 00:05:05,380
So that really just leaves us with one last option.

70
00:05:05,380 --> 00:05:10,060
Remember just a moment ago I told you that there were two possibilities of using asynchronous communication

71
00:05:10,300 --> 00:05:12,490
to solve the issue that we're in right now.

72
00:05:12,510 --> 00:05:13,690
Just take another pause right here.

73
00:05:13,690 --> 00:05:18,520
We'll come back the next video we'll take a look at the second form of asynchronous communication that

74
00:05:18,520 --> 00:05:19,300
we're going to use.