1
00:00:00,840 --> 00:00:06,110
We've now seen how to communicate between different services using synchronous and asynchronous communication.

2
00:00:06,120 --> 00:00:10,510
We're now going to take a look at a second way of using asynchronous communication.

3
00:00:10,550 --> 00:00:14,850
Now I gotta tell you right now that the second way that we're gonna look at it is going to be a little

4
00:00:14,850 --> 00:00:21,210
bit similar to the database for service pattern in that this stuff is going to seem really bizarre and

5
00:00:21,240 --> 00:00:24,100
pretty and efficient but just bear with me.

6
00:00:24,120 --> 00:00:29,070
We're going to go through a pretty deep example to give you an idea of how we're going to use asynchronous

7
00:00:29,070 --> 00:00:33,390
communication to somehow communicate between these different services.

8
00:00:33,420 --> 00:00:39,240
We're going to once again focus on this idea of introducing service D into our e commerce application

9
00:00:39,450 --> 00:00:42,850
that just has three existing services.

10
00:00:42,890 --> 00:00:49,320
The first thing I want to do is to put a better goal or really define exactly what we want service D

11
00:00:49,370 --> 00:00:50,250
to do.

12
00:00:50,270 --> 00:00:54,110
Right now we're just saying oh yeah we're going to show products ordered by a particular user but I

13
00:00:54,110 --> 00:00:58,530
want to be really explicit in saying here are the inputs to the service.

14
00:00:58,550 --> 00:01:03,670
And here is what is expected to respond with whenever it receives a request.

15
00:01:03,680 --> 00:01:07,740
So here's my more exact definition of what service D is supposed to do.

16
00:01:07,760 --> 00:01:14,120
I'm going to say that given the idea of a user I want to show the title and image for every product

17
00:01:14,150 --> 00:01:15,950
that they have ever ordered.

18
00:01:15,980 --> 00:01:19,890
That's the exact precise goal of service D.

19
00:01:19,970 --> 00:01:26,000
Now with that in mind let's try to imagine creating a database that would serve this goal right here

20
00:01:26,030 --> 00:01:27,410
really well.

21
00:01:27,470 --> 00:01:35,050
So here's my idea of how we could add in a database to service D to solve this little feature request.

22
00:01:35,090 --> 00:01:40,280
So I think that we could introduce a database it could be no sequel or sequel based doesn't really matter

23
00:01:40,670 --> 00:01:42,890
with two separate collections of data.

24
00:01:43,010 --> 00:01:47,620
One would be a record of all the different users who have signed up to our application.

25
00:01:47,660 --> 00:01:49,970
We don't really care about a user's email address.

26
00:01:49,970 --> 00:01:51,270
We don't care about their name.

27
00:01:51,290 --> 00:01:53,030
We don't care about their age or address.

28
00:01:53,030 --> 00:01:58,310
The only thing we said for our service as an input is that we need to know the idea of a user and then

29
00:01:58,310 --> 00:02:00,020
show products that they have ordered.

30
00:02:00,080 --> 00:02:05,920
So inside of this user's collection I would record the I.D. of every user who signs up to my app and

31
00:02:05,930 --> 00:02:08,910
on the I.D. of any products they ever order.

32
00:02:09,260 --> 00:02:14,450
And then to actually know what the title and images for every product I could have a separate collection

33
00:02:14,450 --> 00:02:19,100
of products where I record the idea the product its title and its image.

34
00:02:19,100 --> 00:02:23,330
So if I put in some practical data here I might end up with something like this maybe I would have an

35
00:02:23,360 --> 00:02:31,430
I.D. of five and 20 or some products and I would have a title of say pants and shoes and an image of

36
00:02:31,430 --> 00:02:39,130
pants dot j peg and shoes deejay peg and then maybe if some user came along and ordered some product

37
00:02:39,610 --> 00:02:40,930
maybe they have an idea of one.

38
00:02:40,960 --> 00:02:47,050
That's the idea my user and if they ordered products 5 and 20 I could store those inside of an array

39
00:02:47,290 --> 00:02:49,380
like so.

40
00:02:49,530 --> 00:02:51,470
So now can we answer this question.

41
00:02:51,470 --> 00:02:54,200
Can we fulfill this feature using this database.

42
00:02:54,200 --> 00:02:55,370
Well let's walk through it again.

43
00:02:55,760 --> 00:03:01,430
So if I have the idea of a user let's say that's user at one I need to show the title an image for every

44
00:03:01,430 --> 00:03:03,170
product I have ever ordered.

45
00:03:03,170 --> 00:03:03,470
OK.

46
00:03:03,500 --> 00:03:08,900
So we would go into our users collection we'd find the user tidy one we'd find that the product ideas

47
00:03:08,900 --> 00:03:11,040
they have ordered are five and 20.

48
00:03:11,090 --> 00:03:13,190
So we'd then go and look inside of our products collection.

49
00:03:13,220 --> 00:03:15,720
We would find a product with five and 20.

50
00:03:15,770 --> 00:03:21,110
Look at the appropriate title and image for both and then respond with both those to some incoming requests

51
00:03:21,110 --> 00:03:23,060
to service D.

52
00:03:23,090 --> 00:03:25,020
Well it seems like that solves the issue.

53
00:03:25,070 --> 00:03:32,150
So if we had a database with this structure right here we could implement service D very easily.

54
00:03:32,150 --> 00:03:35,320
And what's more service D would be 100 percent self-contained.

55
00:03:35,960 --> 00:03:42,260
So this really turns into a question of how can we create this database and stick in the relevant information

56
00:03:42,260 --> 00:03:43,490
inside there.

57
00:03:43,700 --> 00:03:45,390
That is the challenge in its own right.

58
00:03:45,410 --> 00:03:49,400
And the reason for that is that if we think about the overall structure of our application right now

59
00:03:49,910 --> 00:03:57,130
service D is never really going to be told about whenever a user signs up whenever a product gets created

60
00:03:57,370 --> 00:04:03,910
or whenever a user orders a given product because that information is being sent in requests to service

61
00:04:03,940 --> 00:04:09,890
a b and c and in output from all that is never making its way over to service D.

62
00:04:09,940 --> 00:04:14,680
So right now it would be kind of hard to get any relevant information into this database that we just

63
00:04:14,680 --> 00:04:16,010
imagined.

64
00:04:16,010 --> 00:04:17,080
So that's what we need to solve.

65
00:04:17,110 --> 00:04:25,330
We need to think how we can tell get service A B and C to somehow tell service D about anytime a user

66
00:04:25,330 --> 00:04:29,590
signs up product is created or a user orders a product.

67
00:04:29,590 --> 00:04:35,200
And what's more whenever service a b and c communicates that over we need to figure out how to do that

68
00:04:35,200 --> 00:04:42,100
communication in some kind of way where service a isn't going to fail if service D is not up.

69
00:04:42,100 --> 00:04:47,560
So in other words if we tried to use some synchronous communication to have service a tell service deal

70
00:04:47,560 --> 00:04:48,760
whenever user signs up.

71
00:04:48,760 --> 00:04:52,600
Well once again that's a dependency if that request failed for some reason.

72
00:04:52,750 --> 00:04:55,560
Who knows service they might crash as well.

73
00:04:55,690 --> 00:04:57,630
That's all of our requirements put together.

74
00:04:58,190 --> 00:04:59,680
So how are we going to solve this.

75
00:04:59,680 --> 00:05:03,620
Well that's going to come down to that form of asynchronous communication.

76
00:05:03,880 --> 00:05:10,750
So let's go through this process so we're going to imagine the workflow of how we would get information

77
00:05:10,840 --> 00:05:12,820
into our database right here.

78
00:05:12,990 --> 00:05:19,660
Here is exactly what would happen any time a request comes in to create a product to sign up a user

79
00:05:20,050 --> 00:05:23,450
or to create a or purchase a product create an order.

80
00:05:23,620 --> 00:05:29,950
We're going to have these relevant services emit an event simultaneously describing what just happened

81
00:05:30,160 --> 00:05:31,190
to them.

82
00:05:31,210 --> 00:05:32,520
Let me show you what I mean.

83
00:05:32,620 --> 00:05:37,720
Let's first imagine that we boot up our application for the very first time and we decide to go into

84
00:05:37,720 --> 00:05:43,550
our app and create a couple of different products so maybe we make a request a service be but the goal

85
00:05:43,580 --> 00:05:49,760
of creating a product internally service B would say OK I got this request I'm going to create a product

86
00:05:50,060 --> 00:05:54,290
and save it into my personal database simultaneously.

87
00:05:54,290 --> 00:06:02,450
And here's the key service B would also emit an event over to our service bus and that event might look

88
00:06:02,480 --> 00:06:03,770
a little something like this.

89
00:06:03,770 --> 00:06:10,780
Let me zoom in so you can see this more easily so service B right after saving that new product might

90
00:06:10,780 --> 00:06:17,530
event emit an event that says hey everybody if anyone cares a product was just created and here are

91
00:06:17,530 --> 00:06:21,730
some details about that product maybe it has an I.D. title and an image.

92
00:06:22,540 --> 00:06:26,870
So that event would flow into our event broker over here.

93
00:06:26,980 --> 00:06:33,050
Here's the event bus or event broker event bus would then it take that event and send it off to any

94
00:06:33,050 --> 00:06:34,670
interested services.

95
00:06:34,670 --> 00:06:40,600
So in this case that would be service D a service D would receive this event we would have some code

96
00:06:40,600 --> 00:06:46,810
inside there to receive this event and service D would say OK a product was created as an idea of one

97
00:06:47,110 --> 00:06:49,870
idea pants an image of pants dot j peg.

98
00:06:49,950 --> 00:06:54,770
So service D would take that information and record that event inside of its products table.

99
00:06:54,790 --> 00:07:04,200
So it put in say idea of one dollar pants and pants dot j peg so that's how we would start to get some

100
00:07:04,200 --> 00:07:06,120
information into this database.

101
00:07:06,120 --> 00:07:10,490
We are going to rely upon these other services A B and C emitting events.

102
00:07:10,500 --> 00:07:16,080
Anytime something interesting occurs let's now go through the same process and imagine what would happen

103
00:07:16,080 --> 00:07:21,300
whenever a user signs up to our application so let's imagine a little bit later after we create that

104
00:07:21,300 --> 00:07:24,920
product and I'll update some terminology here.

105
00:07:26,780 --> 00:07:35,440
There we go so maybe a little bit later a user comes and signs up to our application so we get a request

106
00:07:35,440 --> 00:07:38,800
to sign up.

107
00:07:39,130 --> 00:07:43,960
That would come into our service a service a would create a new user inside of its users collection

108
00:07:44,530 --> 00:07:50,650
and then it would emit an event over to this event bus and maybe it would look something like type of

109
00:07:50,710 --> 00:07:57,050
user created and maybe add some data it would have just the idea of the user that was created.

110
00:07:57,060 --> 00:08:02,920
So once again this event would flow over to the event bus the event bus would send that event along

111
00:08:02,950 --> 00:08:09,960
to service d down here inside of service D we would have some code to interpret this event you would

112
00:08:09,960 --> 00:08:12,030
say OK a user was just created.

113
00:08:12,030 --> 00:08:16,740
Well I'm going to save them as a user to my users collection but put down an idea one.

114
00:08:16,740 --> 00:08:22,140
And right now this user has not ordered any products sort of maybe just put in an empty array of product

115
00:08:22,140 --> 00:08:23,360
ideas.

116
00:08:23,430 --> 00:08:26,510
Now I think you can understand where this is going down the last step.

117
00:08:26,510 --> 00:08:32,450
We would imagine really quickly that we get a request to order a product

118
00:08:35,500 --> 00:08:40,430
so that would go to service see I won't change any terminology on this little thing right here just

119
00:08:40,430 --> 00:08:41,420
to save time.

120
00:08:41,520 --> 00:08:46,460
We'd say that requested come into service C service C would say OK I'll create a new order inside of

121
00:08:46,460 --> 00:08:54,180
some collection and then you met an event and maybe that event would look something like order created

122
00:08:54,360 --> 00:09:00,060
and it might have some information tied to it like the idea of the user and the idea of the product

123
00:09:00,210 --> 00:09:07,960
that was created as well so we would have that event flow off to our event bus that would come into

124
00:09:07,960 --> 00:09:16,190
our service D over here once again service D could say OK order was created.

125
00:09:16,190 --> 00:09:20,040
It looks like user of I.D. one ordered a product without one.

126
00:09:20,070 --> 00:09:25,100
So it would update this products idea array right there but in the one and there we go we've now got

127
00:09:25,160 --> 00:09:32,180
our database fully populated and service D can instantly very quickly answer the question what products

128
00:09:32,240 --> 00:09:36,530
has a user with I.D. number one ordered OK.

129
00:09:36,700 --> 00:09:41,660
So that is asynchronous communication that kind of second form that we're going to look at.

130
00:09:41,770 --> 00:09:45,760
That's been a very long video so you can take a pause right here and then do a summary and talk about

131
00:09:45,760 --> 00:09:48,220
some pros and cons of this approach in the next video.