Original subtitles

We've now got a working definition of what a micro service is now.

At the end of last video we were looking at this diagram right here.

And when you were looking at this you might have said to yourself Oh OK.

Micro surfaces are easy.

Oh we have to do is take a feature rapid and service and that's it.

Well unfortunately reality is just a little bit different.

It turns out that when we start working with micro services there are some really big challenges that

we start to run into.

So in this video I want to start to introduce one of these really big challenges.

So here's what it is data management between services.

When I say data management I'm talking about the way in which we store data inside of a service and

how we communicate that data between different services.

Let me take a pause right here and just tell you flat out.

This is a very big very challenging problem.

It is a huge obstacle to effectively using micro services.

The good news is that this problem right here is what we are going to have an unending focus on in this

course.

And by the end of this course you're going to have a couple of different strategies we're working with

this data management problem.

Now let me tell you a little bit more about why this is a problem.

Let me help you understand why this is such a big thing get so a little bit of preamble here a little

bit of background with micro services the way in which we store data and access data is a little bit

weird and what I mean by weird is that it's just a little bit different than what you might be used

to with a monolithic application.

So in the next couple of diagrams we're going to take a look at how we store data and how we access

data in a micro services approach.

So first off how do we store data in a micro services system we might recall the diagram we were looking

at just a moment ago I showed a separate database for every service that we had created so whenever

we are making use of micro services we're going to create a separate database for each service.

If the service actually needs a database if a service doesn't needs a database that's fine.

We're not going to give it one.

But the point is every service gets its own database.

Now that might sound really strange but going to give you a very good reason for this in just a moment.

First let me also show you how we access data and once again this is going to be a little bit strange

to access data on I'm not going to tell you exactly how we're going to access data I'm going to tell

you how we are not going to access data.

So we are never going to access data by reaching from one service into another services database.

So under no circumstance will we ever have service say right here.

Try to reach into the database for service B.

And once again I'm going to give you a very good reason for this in just a moment OK.

So in total here are the two big kind of surprising facts that I've now mentioned.

First off each service is going to get its own database if it needs one.

And secondly services are never going to reach into another services database.

Now let me tell you why this is why are we doing this.

Because these seem like two very strange rules there's a couple of different reasons.

First I want you to understand that this whole idea of giving every service its own database is known

as a pattern the pattern is called database or service.

So as you'd expect that just means every service has its own database.

Here are a couple of reasons and this is by no means an exhaustive list.

The first reason and this is the really big reason is that we want every service we create to run independently

of other services.

So let me show you a quick diagram to help you understand why giving each service its own database is

going to help with that all right.

So first let's imagine a scenario where we have every service using the same common database.

So maybe just one database right here we'll call it database for everything.

The problem with this approach is that if anything bad ever happens to this database all of our services

are going to crash immediately.

The other big problem is that scaling this database right here would be really challenging if every

service inside of application uses the same database.

We're going to scale up that one database instance or that one database to service all of the different

services of our app.

It would be a lot easier to scale just the databases that need additional capacity or throughput.

The other scenario that we could run in.

Let's imagine that we've got service a reaching out to database these service right here if anything

ever goes wrong with the database be right there then all of sudden service day is going to start to

crash because we have introduced a dependency between service say and service B.

So if a request comes into service a and feature a tries to reach over to this database and something

is wrong with that database boom service say is going to crash as well.

And so rather than just losing service B we would now also be losing service a.

So why given each date of each service its own database and making sure that each service only uses

its own database we dramatically increase the uptime of our entire system now.

Next reason let's see right here the next reason that we have this database per service pattern is that

the schema or structure of a database might change unexpectedly.

So quick example of this as well I want you to imagine for a second that we've got service a reaching

directly over to database b over here.

And again this is not what we want.

I'm giving you an example of why we do not do this.

Let's imagine that future Ray usually runs a query of something like get user inside a b and usually

database B returns an object that has a name of Jill or something like that.

Whatever the name is the point is that's got a key of name right there.

Let's imagine that for some reason service be the team that is in charge of it decides to change the

schema or the structure of this database and maybe they decide that rather than giving every user a

name property maybe they want to call that first name instead let's further imagine that maybe the team

in charge of service B does not tell the team in charge of service say about the change to the schema

right here.

If that were to happen then the next time that service a makes a query down here they're going to get

back an object that has a first name property instead of name service say was probably not configured

to expect to see a property of first name.

And so now we might start to have some issues start to arise and service a all because we tried to rely

upon a database located in a different service and that second database right there had its structure

or schema change at some point in time the last reason I'm going to throw out your really quickly is

that some services might be able to function more efficiently if they are using a different type of

database.

So for example maybe one service can run more efficiently if it uses Mongo or Mongo DB as opposed to

post crests or something similar to that this whole database per service pattern might seem a little

bit surprising and you might already be saying Steven there's no way this is how it's done there's no

way we're creating a separate database for every service.

Well this is reality.

This is how every successful engineering team out there is using micro services.

They are all every last on them following this pattern right here.

One database or service.

OK.

So now we've set up this kind of weird pattern right here.

We still have not really touched on why data management between services is really challenging.

So quick pause right here we're going to come back next video and start to expand on this in just a

moment.