In the last video we were looking at a very simple e commerce application and we saw that we start to
introduce this new service down here that relies upon data from these other services.
Life starts to get really challenging really quickly if we are going to follow that pattern of database
per service because service cannot reach directly over to this database.
This one or this one.
So in this video we're going to take a look at two very general strategies that we can use to solve
this problem these two general strategies that we're going to use are really talking about how we communicate
between different services.
There are two general strategies referred to as synchronous or sync and asynchronous or async.
I want you to understand right away that in the micro services world these terms do not mean what they
mean in the javascript world.
So JavaScript has its own definition of sync and async that is not the same thing as sinking a sink
in micro services.
Very different terms.
So let's first begin by taking a look at the definition of a synchronous communication style.
So in this synchronous world if we are going to communicate between different services using this pattern
we're going to have one service communicate with another directly using requests.
This doesn't necessarily have to be an HDP request or a request that exchanges Jason.
It is just some kind of direct request whatever its form is a direct request from service they overdue
to service B to fetch some information rather than taking a look at the definition of async.
Let's first take a look at an example of synchronous communication right away.
All right.
So we're going to apply this idea of synchronous communication to the example that we're looking at
just a moment ago.
So once again we are imagining this e-commerce application where we've got users products and orders
down here in service see so if we were going to use synchronous communication we can imagine that a
request might come into service D and I might say show me all the products that I've been ordered by
the user with I.D. number one the first thing that service D might do is make a direct request over
to service a again that might be a plain H TTP request might exchanged Jason whatever its form is it
is a direct request from D over to a service D would then check to make sure that maybe that user exists
you would then get a response back and if that user exists it might might then make a follow up request
over to service C and find all the orders that have been created for this user it would get back a response
and then finally make a request over to service B and say give me details about these particular products.
So after making those three different requests service t would then have all the information it needs
to respond to the overall request at no point time did service D reach directly into any of these databases
over here.
So we have not violated any big rules around our database per service pattern and there's some definite
upsides and downsides to this approach.
So let's take a look at those right away the upsides to this are that using synchronous communication
is pretty easy to understand.
I think that by pretty much just looking at this diagram you probably got a reasonable idea of how this
stuff works we create a service it makes requests to other services to get data that's it so conceptually
not the worst thing.
The other nice thing about this approach is that service D is not going to need a database that's service
D right here we won't have to provision maintain pay for a database service D relies upon data coming
from these other services that have their own databases so noted database required but like I said there
are some really big downsides to this approach as well.
The downsides are.
First off it introduces a dependency between service D and those other three.
That means that if any of these services go down for any reason like let's say service say if that goes
down right there now all the sudden service D is not going to work correctly either so service D is
going to fail entirely as well.
That means that we might lose the functionality of big pieces of our application at some point time
if some key critical service starts to go down the next big issue is that if any of these inter service
requests fail the overall request is going to fail as well.
So very similar to what we've just said about service a failing if for some reason this request right
here fails.
Well now we don't know if that user exists.
So chances are we would throw an error and respond to the request and say sorry but an error occurred
can't help you the next big downside is that this entire request is only as fast as the slowest request.
Let's imagine that this request over to the user servers right here takes about 10 milliseconds and
then maybe the next one down here to get all these products ordered by that person takes another 10
milliseconds and then finally service be right here maybe for some crazy reason that takes 20 seconds
so twenty seconds to make that final request right there.
So that means that overall we're gonna have 20 and 20 milliseconds to complete the overall request.
So we're only ever going to be as fast as the slowest request and then finally this one's a little bit
hard to understand but this can introduce a web of dependencies that starts to really spiral out of
control.
But the key thing to keep in mind around micros services different diagram right here really quickly
is that we don't necessarily know what some other service is doing internally.
So if you and I are trying to develop service D we might know that we need to make a request to a B
and C but we might not know what those things are doing internally.
And it turns out that service say internally to work correctly might need to make its own request over
to service Q and service Q in turn might need to make its own request to Z and X down here.
And so you can really start to imagine that to service any given request like the one coming from service
to you right here.
There might be a huge multitude of requests going on behind the scenes dozens if not hundreds of requests
just a service.
This one simple original request that came in 2 D.
And once again if any of these things go wrong like if that fails right there or if that fails right
there.
Well all sudden the entire overall request fails as well.
And once again we're only as fast as the slowest operation so in practice since communication.
Well there's some definite upsides but there are some gigantic operational downsides as well.
OK.
So we've now got a pretty reasonable understanding of synchronous communication and so that just leaves
async.
Let's take a pause right here async is a little bit more confusing.
We'll take a look at how that works in just a moment.