1
00:00:01,040 --> 00:00:05,680
In last video we discussed some reasons to have one database per service that we create.

2
00:00:05,680 --> 00:00:10,510
Now in this video I want to kind of circle this whole idea back to something we looked at just a moment

3
00:00:10,510 --> 00:00:14,420
ago where I said that data management between services was really challenging.

4
00:00:14,500 --> 00:00:20,770
So we're going to take a look at a very simple application that we might try to build using this database

5
00:00:20,800 --> 00:00:27,250
per service approach and you're going to see that very quickly we run into some gigantic data management

6
00:00:27,280 --> 00:00:28,360
issues.

7
00:00:28,630 --> 00:00:32,910
Now to help you understand this quick example let's take a look at a little diagram here.

8
00:00:32,920 --> 00:00:35,870
So let's imagine that this is the application that we're going to build.

9
00:00:35,890 --> 00:00:41,830
So very simple in nature it's an e commerce application and it really has just three very simple functions

10
00:00:41,830 --> 00:00:42,790
to it.

11
00:00:42,790 --> 00:00:45,120
First we have the ability to sign up.

12
00:00:45,250 --> 00:00:50,110
We have the ability to list out some products that a user can buy like hats pants and shoes.

13
00:00:50,380 --> 00:00:53,980
And we have the ability to actually buy those products as well.

14
00:00:53,980 --> 00:00:59,970
Now let's first imagine building this very simple application with a monolith style approach so remember

15
00:00:59,980 --> 00:01:05,200
with a monolith we've got all of our code inside of one code base and we've got one database to service

16
00:01:05,200 --> 00:01:07,210
that.

17
00:01:07,280 --> 00:01:10,250
So here's a sort of monolithic style approach.

18
00:01:10,250 --> 00:01:15,050
We've got our monolithic server and it has some code to assign up the user list of all the products

19
00:01:15,170 --> 00:01:17,240
and purchase a product.

20
00:01:17,240 --> 00:01:22,490
Now of course our monolithic server probably needs to store data somewhere so maybe we create a database

21
00:01:22,940 --> 00:01:25,450
to service each of these different functions.

22
00:01:25,450 --> 00:01:31,910
So inside of this one singular database we might have a collection or a table of users a collection

23
00:01:31,910 --> 00:01:35,850
or table of products and the same for orders as well.

24
00:01:35,850 --> 00:01:36,200
OK.

25
00:01:36,200 --> 00:01:38,700
This all looks pretty simple and straightforward.

26
00:01:38,720 --> 00:01:42,370
Let's now start to add in a new feature to our monolith.

27
00:01:42,500 --> 00:01:48,170
Let's say that we want to add in a new feature where we can show all the products ordered by a very

28
00:01:48,170 --> 00:01:50,340
particular user.

29
00:01:50,360 --> 00:01:51,770
How would we implement that thing.

30
00:01:52,310 --> 00:01:56,960
Well if you really think about it we kind of need information from all of these different collections

31
00:01:56,960 --> 00:01:58,310
are tables right here.

32
00:01:58,310 --> 00:02:03,380
First we might want to take a look at the user collection and make sure that the particular user that

33
00:02:03,380 --> 00:02:06,020
we're trying to look up information for exists.

34
00:02:06,020 --> 00:02:12,920
We might try to then look in the orders collection and find the order that a user has created and maybe

35
00:02:12,920 --> 00:02:19,290
on that order we would see the I.D. of each product that was actually ordered and then if we wanted

36
00:02:19,290 --> 00:02:21,590
to actually show information about those products.

37
00:02:21,630 --> 00:02:27,380
Well we have to do a query over to the product's collection as well so we're talking about accessing

38
00:02:27,380 --> 00:02:33,200
these three different sources of information to implement this one single feature and inside of a monolithic

39
00:02:33,200 --> 00:02:33,940
server.

40
00:02:33,960 --> 00:02:35,440
Yeah this is all totally fine.

41
00:02:35,450 --> 00:02:40,900
No issue whatsoever OK so now let's now take this entire idea right here.

42
00:02:40,900 --> 00:02:45,050
This simple e commerce application but drop off that last feature.

43
00:02:45,050 --> 00:02:50,720
So how would we go back to this kind of scenario right here and split this monolithic server into three

44
00:02:50,780 --> 00:02:52,940
separate micro services.

45
00:02:52,940 --> 00:02:58,970
Well it might look something like this right here so we've got service say that would have some code

46
00:02:58,970 --> 00:03:00,680
inside of it to sign up a user.

47
00:03:00,830 --> 00:03:04,620
And as we just discussed it's going to have its own little database.

48
00:03:04,620 --> 00:03:08,630
So inside that database we'll probably record all the users who sign up to our app.

49
00:03:09,020 --> 00:03:14,730
We'll have service B for products and service C down here to purchase a product which is really to like

50
00:03:14,750 --> 00:03:19,430
create a order and say that we want to purchase something and so service B and C will probably have

51
00:03:19,430 --> 00:03:22,580
their own databases as well.

52
00:03:22,580 --> 00:03:26,480
Now let's imagine once again that we want to add in a new feature.

53
00:03:26,480 --> 00:03:29,880
So we want to add in a fourth service your service D.

54
00:03:30,230 --> 00:03:37,760
And the goal of service D is to give us the ability to show not products but orders made by a very particular

55
00:03:37,790 --> 00:03:39,050
user.

56
00:03:39,050 --> 00:03:43,880
So if we wanted to follow the same pattern that we used back in that model that style approach we could

57
00:03:44,300 --> 00:03:52,820
say that we want to have this service right here reach out to that database reach out to database B

58
00:03:53,600 --> 00:03:59,830
and C and it would have to do that if it wanted to get information about the user find the order they

59
00:03:59,830 --> 00:04:03,430
had created and then find details about those given products.

60
00:04:03,510 --> 00:04:10,360
But as we just discussed a moment ago in this micros services style world we do not allow a service

61
00:04:10,540 --> 00:04:15,070
to reach out to databases owned by other services.

62
00:04:15,070 --> 00:04:19,870
And so the question here very quickly becomes how would we create service D.

63
00:04:20,170 --> 00:04:22,890
How in the world would that happen.

64
00:04:22,960 --> 00:04:28,810
How can we somehow get information required to implement this feature right here without reaching into

65
00:04:28,810 --> 00:04:30,210
these databases.

66
00:04:30,370 --> 00:04:32,800
And that is the crux of the issue.

67
00:04:32,860 --> 00:04:39,340
That is why data management between services can be really really challenging.

68
00:04:39,340 --> 00:04:41,680
Of course there's a lot of other tiny little problems along the way.

69
00:04:41,890 --> 00:04:43,370
But that's gone to the core issue here.

70
00:04:43,390 --> 00:04:47,380
We don't allow these services to interact with each other's databases.

71
00:04:47,380 --> 00:04:52,630
And so anytime we want to add in a new function or change functionality of an existing service and we

72
00:04:52,630 --> 00:04:56,070
want to get access to existing data how do we do that.

73
00:04:56,080 --> 00:04:58,470
It's a challenging little problem.

74
00:04:58,610 --> 00:04:59,960
Let's take a pause right here.

75
00:04:59,960 --> 00:05:04,280
We're going to come back next video and I'm going to outline two general methodologies that we're going

76
00:05:04,280 --> 00:05:07,280
to use that would allow us to implement service D.