Original subtitles

In last video we discussed some reasons to have one database per service that we create.

Now in this video I want to kind of circle this whole idea back to something we looked at just a moment

ago where I said that data management between services was really challenging.

So we're going to take a look at a very simple application that we might try to build using this database

per service approach and you're going to see that very quickly we run into some gigantic data management

issues.

Now to help you understand this quick example let's take a look at a little diagram here.

So let's imagine that this is the application that we're going to build.

So very simple in nature it's an e commerce application and it really has just three very simple functions

to it.

First we have the ability to sign up.

We have the ability to list out some products that a user can buy like hats pants and shoes.

And we have the ability to actually buy those products as well.

Now let's first imagine building this very simple application with a monolith style approach so remember

with a monolith we've got all of our code inside of one code base and we've got one database to service

that.

So here's a sort of monolithic style approach.

We've got our monolithic server and it has some code to assign up the user list of all the products

and purchase a product.

Now of course our monolithic server probably needs to store data somewhere so maybe we create a database

to service each of these different functions.

So inside of this one singular database we might have a collection or a table of users a collection

or table of products and the same for orders as well.

OK.

This all looks pretty simple and straightforward.

Let's now start to add in a new feature to our monolith.

Let's say that we want to add in a new feature where we can show all the products ordered by a very

particular user.

How would we implement that thing.

Well if you really think about it we kind of need information from all of these different collections

are tables right here.

First we might want to take a look at the user collection and make sure that the particular user that

we're trying to look up information for exists.

We might try to then look in the orders collection and find the order that a user has created and maybe

on that order we would see the I.D. of each product that was actually ordered and then if we wanted

to actually show information about those products.

Well we have to do a query over to the product's collection as well so we're talking about accessing

these three different sources of information to implement this one single feature and inside of a monolithic

server.

Yeah this is all totally fine.

No issue whatsoever OK so now let's now take this entire idea right here.

This simple e commerce application but drop off that last feature.

So how would we go back to this kind of scenario right here and split this monolithic server into three

separate micro services.

Well it might look something like this right here so we've got service say that would have some code

inside of it to sign up a user.

And as we just discussed it's going to have its own little database.

So inside that database we'll probably record all the users who sign up to our app.

We'll have service B for products and service C down here to purchase a product which is really to like

create a order and say that we want to purchase something and so service B and C will probably have

their own databases as well.

Now let's imagine once again that we want to add in a new feature.

So we want to add in a fourth service your service D.

And the goal of service D is to give us the ability to show not products but orders made by a very particular

user.

So if we wanted to follow the same pattern that we used back in that model that style approach we could

say that we want to have this service right here reach out to that database reach out to database B

and C and it would have to do that if it wanted to get information about the user find the order they

had created and then find details about those given products.

But as we just discussed a moment ago in this micros services style world we do not allow a service

to reach out to databases owned by other services.

And so the question here very quickly becomes how would we create service D.

How in the world would that happen.

How can we somehow get information required to implement this feature right here without reaching into

these databases.

And that is the crux of the issue.

That is why data management between services can be really really challenging.

Of course there's a lot of other tiny little problems along the way.

But that's gone to the core issue here.

We don't allow these services to interact with each other's databases.

And so anytime we want to add in a new function or change functionality of an existing service and we

want to get access to existing data how do we do that.

It's a challenging little problem.

Let's take a pause right here.

We're going to come back next video and I'm going to outline two general methodologies that we're going

to use that would allow us to implement service D.