Original subtitles

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.