1
00:00:00,810 --> 00:00:05,710
In the last video we were looking at a very simple e commerce application and we saw that we start to

2
00:00:05,710 --> 00:00:10,610
introduce this new service down here that relies upon data from these other services.

3
00:00:10,630 --> 00:00:15,550
Life starts to get really challenging really quickly if we are going to follow that pattern of database

4
00:00:15,580 --> 00:00:20,110
per service because service cannot reach directly over to this database.

5
00:00:20,110 --> 00:00:21,710
This one or this one.

6
00:00:21,750 --> 00:00:26,440
So in this video we're going to take a look at two very general strategies that we can use to solve

7
00:00:26,440 --> 00:00:32,270
this problem these two general strategies that we're going to use are really talking about how we communicate

8
00:00:32,450 --> 00:00:34,660
between different services.

9
00:00:34,670 --> 00:00:41,150
There are two general strategies referred to as synchronous or sync and asynchronous or async.

10
00:00:41,150 --> 00:00:47,090
I want you to understand right away that in the micro services world these terms do not mean what they

11
00:00:47,090 --> 00:00:48,710
mean in the javascript world.

12
00:00:48,720 --> 00:00:55,200
So JavaScript has its own definition of sync and async that is not the same thing as sinking a sink

13
00:00:55,280 --> 00:00:56,560
in micro services.

14
00:00:56,570 --> 00:00:58,440
Very different terms.

15
00:00:58,610 --> 00:01:05,460
So let's first begin by taking a look at the definition of a synchronous communication style.

16
00:01:05,580 --> 00:01:10,740
So in this synchronous world if we are going to communicate between different services using this pattern

17
00:01:11,070 --> 00:01:16,270
we're going to have one service communicate with another directly using requests.

18
00:01:16,320 --> 00:01:21,420
This doesn't necessarily have to be an HDP request or a request that exchanges Jason.

19
00:01:21,420 --> 00:01:28,280
It is just some kind of direct request whatever its form is a direct request from service they overdue

20
00:01:28,320 --> 00:01:34,110
to service B to fetch some information rather than taking a look at the definition of async.

21
00:01:34,170 --> 00:01:38,520
Let's first take a look at an example of synchronous communication right away.

22
00:01:38,760 --> 00:01:39,040
All right.

23
00:01:39,060 --> 00:01:43,760
So we're going to apply this idea of synchronous communication to the example that we're looking at

24
00:01:43,770 --> 00:01:45,230
just a moment ago.

25
00:01:45,240 --> 00:01:51,330
So once again we are imagining this e-commerce application where we've got users products and orders

26
00:01:51,840 --> 00:01:58,060
down here in service see so if we were going to use synchronous communication we can imagine that a

27
00:01:58,060 --> 00:02:03,260
request might come into service D and I might say show me all the products that I've been ordered by

28
00:02:03,260 --> 00:02:10,310
the user with I.D. number one the first thing that service D might do is make a direct request over

29
00:02:10,310 --> 00:02:18,230
to service a again that might be a plain H TTP request might exchanged Jason whatever its form is it

30
00:02:18,230 --> 00:02:24,980
is a direct request from D over to a service D would then check to make sure that maybe that user exists

31
00:02:25,380 --> 00:02:30,380
you would then get a response back and if that user exists it might might then make a follow up request

32
00:02:30,920 --> 00:02:38,090
over to service C and find all the orders that have been created for this user it would get back a response

33
00:02:38,240 --> 00:02:44,190
and then finally make a request over to service B and say give me details about these particular products.

34
00:02:44,260 --> 00:02:48,830
So after making those three different requests service t would then have all the information it needs

35
00:02:49,040 --> 00:02:56,110
to respond to the overall request at no point time did service D reach directly into any of these databases

36
00:02:56,110 --> 00:02:56,940
over here.

37
00:02:57,040 --> 00:03:03,690
So we have not violated any big rules around our database per service pattern and there's some definite

38
00:03:03,750 --> 00:03:06,130
upsides and downsides to this approach.

39
00:03:06,130 --> 00:03:12,960
So let's take a look at those right away the upsides to this are that using synchronous communication

40
00:03:12,990 --> 00:03:14,860
is pretty easy to understand.

41
00:03:14,880 --> 00:03:18,840
I think that by pretty much just looking at this diagram you probably got a reasonable idea of how this

42
00:03:18,840 --> 00:03:26,010
stuff works we create a service it makes requests to other services to get data that's it so conceptually

43
00:03:26,070 --> 00:03:27,590
not the worst thing.

44
00:03:27,720 --> 00:03:32,970
The other nice thing about this approach is that service D is not going to need a database that's service

45
00:03:32,970 --> 00:03:39,450
D right here we won't have to provision maintain pay for a database service D relies upon data coming

46
00:03:39,450 --> 00:03:46,790
from these other services that have their own databases so noted database required but like I said there

47
00:03:46,790 --> 00:03:49,970
are some really big downsides to this approach as well.

48
00:03:49,970 --> 00:03:50,900
The downsides are.

49
00:03:50,930 --> 00:03:57,000
First off it introduces a dependency between service D and those other three.

50
00:03:57,060 --> 00:04:02,220
That means that if any of these services go down for any reason like let's say service say if that goes

51
00:04:02,220 --> 00:04:08,160
down right there now all the sudden service D is not going to work correctly either so service D is

52
00:04:08,160 --> 00:04:11,280
going to fail entirely as well.

53
00:04:11,340 --> 00:04:17,220
That means that we might lose the functionality of big pieces of our application at some point time

54
00:04:17,250 --> 00:04:23,040
if some key critical service starts to go down the next big issue is that if any of these inter service

55
00:04:23,040 --> 00:04:26,690
requests fail the overall request is going to fail as well.

56
00:04:26,720 --> 00:04:32,130
So very similar to what we've just said about service a failing if for some reason this request right

57
00:04:32,130 --> 00:04:33,570
here fails.

58
00:04:33,570 --> 00:04:35,640
Well now we don't know if that user exists.

59
00:04:35,640 --> 00:04:40,260
So chances are we would throw an error and respond to the request and say sorry but an error occurred

60
00:04:40,440 --> 00:04:48,830
can't help you the next big downside is that this entire request is only as fast as the slowest request.

61
00:04:48,930 --> 00:04:54,710
Let's imagine that this request over to the user servers right here takes about 10 milliseconds and

62
00:04:54,710 --> 00:05:01,260
then maybe the next one down here to get all these products ordered by that person takes another 10

63
00:05:01,260 --> 00:05:07,740
milliseconds and then finally service be right here maybe for some crazy reason that takes 20 seconds

64
00:05:08,700 --> 00:05:11,790
so twenty seconds to make that final request right there.

65
00:05:11,810 --> 00:05:18,130
So that means that overall we're gonna have 20 and 20 milliseconds to complete the overall request.

66
00:05:18,280 --> 00:05:24,800
So we're only ever going to be as fast as the slowest request and then finally this one's a little bit

67
00:05:24,800 --> 00:05:30,920
hard to understand but this can introduce a web of dependencies that starts to really spiral out of

68
00:05:30,920 --> 00:05:32,140
control.

69
00:05:32,280 --> 00:05:36,290
But the key thing to keep in mind around micros services different diagram right here really quickly

70
00:05:36,860 --> 00:05:41,180
is that we don't necessarily know what some other service is doing internally.

71
00:05:41,270 --> 00:05:46,040
So if you and I are trying to develop service D we might know that we need to make a request to a B

72
00:05:46,040 --> 00:05:49,770
and C but we might not know what those things are doing internally.

73
00:05:49,880 --> 00:05:54,860
And it turns out that service say internally to work correctly might need to make its own request over

74
00:05:54,860 --> 00:06:00,880
to service Q and service Q in turn might need to make its own request to Z and X down here.

75
00:06:00,980 --> 00:06:06,530
And so you can really start to imagine that to service any given request like the one coming from service

76
00:06:06,530 --> 00:06:07,310
to you right here.

77
00:06:07,430 --> 00:06:14,300
There might be a huge multitude of requests going on behind the scenes dozens if not hundreds of requests

78
00:06:14,440 --> 00:06:15,290
just a service.

79
00:06:15,290 --> 00:06:19,620
This one simple original request that came in 2 D.

80
00:06:19,640 --> 00:06:23,990
And once again if any of these things go wrong like if that fails right there or if that fails right

81
00:06:23,990 --> 00:06:24,620
there.

82
00:06:24,650 --> 00:06:28,940
Well all sudden the entire overall request fails as well.

83
00:06:28,940 --> 00:06:35,340
And once again we're only as fast as the slowest operation so in practice since communication.

84
00:06:35,340 --> 00:06:41,740
Well there's some definite upsides but there are some gigantic operational downsides as well.

85
00:06:42,900 --> 00:06:43,180
OK.

86
00:06:43,210 --> 00:06:47,500
So we've now got a pretty reasonable understanding of synchronous communication and so that just leaves

87
00:06:47,590 --> 00:06:48,370
async.

88
00:06:48,400 --> 00:06:51,240
Let's take a pause right here async is a little bit more confusing.

89
00:06:51,340 --> 00:06:53,340
We'll take a look at how that works in just a moment.