1
00:00:01,090 --> 00:00:05,430
In the last video we walked through a second form of asynchronous communication that that was pretty

2
00:00:05,430 --> 00:00:06,320
darn crazy.

3
00:00:06,330 --> 00:00:10,950
Remember I did tell you at the start of the video that this pattern was going to seem really bizarre

4
00:00:10,980 --> 00:00:12,290
and inefficient.

5
00:00:12,510 --> 00:00:17,520
But before we entirely walk away from this pattern let's take a look at some pros and cons and get a

6
00:00:17,520 --> 00:00:21,260
better idea of whether or not this is really something we want to try out.

7
00:00:21,360 --> 00:00:21,570
OK.

8
00:00:21,600 --> 00:00:23,220
So here's some pros and cons.

9
00:00:23,550 --> 00:00:30,300
So on the plus side of this approach service D has zero dependencies on other services.

10
00:00:30,300 --> 00:00:35,220
Now when I say zero dependencies I'm talking about what happens whenever a request comes into service

11
00:00:35,230 --> 00:00:42,470
D can service D answer some request about what products a user has ordered without reaching out to any

12
00:00:42,470 --> 00:00:43,340
other service.

13
00:00:43,340 --> 00:00:44,510
The answer is yes.

14
00:00:44,510 --> 00:00:50,270
Service D does not have immediate need of any other service to answer an incoming request.

15
00:00:50,270 --> 00:00:54,760
It does rely upon other services to get some information to store inside this database.

16
00:00:54,860 --> 00:00:57,530
But those are kind of indirect dependencies.

17
00:00:57,590 --> 00:01:04,980
If SERVICE A B and C go down and they entirely disappear service D is still going to work 100 percent

18
00:01:04,980 --> 00:01:07,280
correctly every single time.

19
00:01:07,380 --> 00:01:11,880
And so we would say that service D it really doesn't have any other dependencies.

20
00:01:11,900 --> 00:01:17,510
The other big benefit here is that service D is going to be extremely fast compared to the other two

21
00:01:17,510 --> 00:01:18,710
approaches that we looked at.

22
00:01:18,800 --> 00:01:23,720
And the reason for that is that service D has all the products that a user has ordered inside of and

23
00:01:23,720 --> 00:01:28,880
immediately available database and so can reach into this database scraps information and immediately

24
00:01:28,880 --> 00:01:34,130
respond to some request and it can do that once again without having to make a direct request to services

25
00:01:34,190 --> 00:01:38,260
A B or C now about the downsides.

26
00:01:38,290 --> 00:01:41,110
Well the downside here is data duplication.

27
00:01:41,140 --> 00:01:46,160
We are now talking about directly duplicating data between different services.

28
00:01:46,180 --> 00:01:52,030
Remember the entire key here was that whenever requests came in to sign up a user to create a product

29
00:01:52,750 --> 00:01:58,450
or to purchase a product those services were going to store information about an order about a product

30
00:01:58,510 --> 00:02:01,980
or that user signing up inside of its own local database.

31
00:02:01,970 --> 00:02:06,550
And then we took it that information about the user thus created or the product or the order and also

32
00:02:06,550 --> 00:02:09,430
stored it inside of the second database down here.

33
00:02:09,430 --> 00:02:12,220
Now we did not actually store the entire record persay.

34
00:02:12,250 --> 00:02:18,190
That's why back here when we spoke about really refining the requirements we said specifically the title

35
00:02:18,190 --> 00:02:19,720
in the image for every product.

36
00:02:19,720 --> 00:02:24,730
So product might also have information about its price its reviews all that kind of other stuff and

37
00:02:24,730 --> 00:02:30,550
we're only storing the title and the image so we're not strictly 100 percent duplicating data but certainly

38
00:02:30,550 --> 00:02:33,230
there is some duplication occurring here.

39
00:02:33,400 --> 00:02:38,830
Now that might sound like a really bad thing because hey we're paying for some extra storage but I'm

40
00:02:38,830 --> 00:02:41,800
going to come down really hard on you really hard.

41
00:02:41,800 --> 00:02:46,210
If you come into the queue a discussion and you complain about paying for extra storage.

42
00:02:46,210 --> 00:02:51,130
Let me tell you why right now let me put to rest any concerns about paying for extra storage.

43
00:02:51,130 --> 00:02:56,710
OK we're going to a quick aside here so I did a little bit of research right now at the time on recording

44
00:02:56,710 --> 00:03:02,160
this video in order to get a gigabyte worth of storage using ASR.

45
00:03:02,170 --> 00:03:06,460
My Eskew L or Google cloud my ask l or eight of us.

46
00:03:06,490 --> 00:03:11,520
My S Q Well it's one C eleven and a half cents on ASR.

47
00:03:11,590 --> 00:03:17,310
It's 17 cents and eleven to half cents on eight of us to get one gigabyte of storage for one month.

48
00:03:17,320 --> 00:03:21,580
So that's kind of a metric that's how much we have to pay for each of these providers to get one gigabyte

49
00:03:21,600 --> 00:03:23,110
a storage for one month.

50
00:03:23,830 --> 00:03:30,400
So I was kind of curious how much does it really cost to store the idea of some product well inside

51
00:03:30,400 --> 00:03:35,170
of this blue box right here you're going to see a ton of really neat text.

52
00:03:35,350 --> 00:03:41,620
So what that is right there is the API response from a W.S. or really Amazon with all the information

53
00:03:41,620 --> 00:03:43,420
about some product that they are selling.

54
00:03:43,420 --> 00:03:46,000
So this is the definition of a product.

55
00:03:46,000 --> 00:03:48,520
According to Amazon for something they are actually selling.

56
00:03:48,520 --> 00:03:51,480
So this is some pretty realistic information right here.

57
00:03:52,470 --> 00:03:56,460
So it's kind of curious what does what is the size of that information.

58
00:03:56,500 --> 00:03:58,580
Information for one single product.

59
00:03:58,590 --> 00:04:00,370
You'll notice that this is just on data.

60
00:04:00,510 --> 00:04:06,330
And so inside up here is a lot of keys and double quotes and curly braces and whatnot.

61
00:04:06,330 --> 00:04:09,330
And that is all information that would normally not be stored inside the database.

62
00:04:09,360 --> 00:04:10,500
But I said Yo what the heck.

63
00:04:10,500 --> 00:04:14,880
Worst case scenario what is the size of that information right there.

64
00:04:14,890 --> 00:04:18,170
It turns out that it's about twelve hundred bytes or so.

65
00:04:18,180 --> 00:04:19,410
So we did a little calculation.

66
00:04:19,440 --> 00:04:22,530
I said OK we got twelve hundred bytes or so.

67
00:04:22,680 --> 00:04:24,280
That's that many gigabytes.

68
00:04:24,360 --> 00:04:27,480
Times eleven a half cents per gigabyte per month.

69
00:04:27,480 --> 00:04:33,690
And then I figured what would it cost to store a hundred million products that were this size inside

70
00:04:33,690 --> 00:04:34,820
of some database.

71
00:04:34,820 --> 00:04:38,790
And the answer is 14 dollars one hundred million products.

72
00:04:38,790 --> 00:04:39,990
Fourteen dollars.

73
00:04:40,160 --> 00:04:45,360
Can we afford fourteen dollars to store some extra data inside of a micro services application.

74
00:04:45,360 --> 00:04:49,100
The answer is unequivocally yes.

75
00:04:49,190 --> 00:04:50,460
And for extra storage.

76
00:04:50,460 --> 00:04:58,720
That is not a downside because storage in the modern world is relatively free so for me data duplication.

77
00:04:58,780 --> 00:04:59,170
OK.

78
00:04:59,180 --> 00:05:02,930
Maybe we are going to end up with some straight stale data over time which is something that we are

79
00:05:02,930 --> 00:05:04,060
going to discuss later on.

80
00:05:04,100 --> 00:05:05,220
But as far as the price.

81
00:05:05,240 --> 00:05:08,110
No that's that's not a cause for concern.

82
00:05:08,200 --> 00:05:09,940
Period.

83
00:05:09,990 --> 00:05:10,290
All right.

84
00:05:10,320 --> 00:05:13,330
Now the last one here last downside hard to understand.

85
00:05:13,390 --> 00:05:15,180
Yeah I would definitely say so.

86
00:05:15,300 --> 00:05:21,120
This entire idea of having all of our services e-mail events and listening for events that is a lot

87
00:05:21,120 --> 00:05:23,430
of overhead and that's a lot of extra code for us to write.

88
00:05:23,430 --> 00:05:25,620
Lot of extra stuff to understand.

89
00:05:25,620 --> 00:05:28,410
So there are some definite downsides to this approach.

90
00:05:28,410 --> 00:05:35,970
But as far as providing a superior performance in uptime for our users this form of asynchronous communication

91
00:05:36,330 --> 00:05:37,510
no two ways about it.

92
00:05:37,560 --> 00:05:40,180
This is the way to go.

93
00:05:40,260 --> 00:05:46,170
And so as you can probably guess in this course we're going to focus on this form of asynchronous communication.

94
00:05:46,260 --> 00:05:48,430
We're going to create a lot of different services.

95
00:05:48,510 --> 00:05:50,950
They're going to have incoming requests.

96
00:05:50,970 --> 00:05:53,400
The service is going to do something locally with that request.

97
00:05:53,400 --> 00:05:57,000
And if it makes a change to any data it's going to emit an event.

98
00:05:57,030 --> 00:06:02,370
Other services will then wait on around listen for events to come in and eventually populate databases

99
00:06:02,370 --> 00:06:07,210
that look like this right here to answer some very specific queries.

100
00:06:07,230 --> 00:06:07,500
All right.

101
00:06:07,590 --> 00:06:12,060
So now that we've got some idea of this form of async stuff let's take a pause right here.

102
00:06:12,060 --> 00:06:14,990
We're going to start working on our first project in the next video.