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.