All language subtitles for 011-Pros and Cons of Async Communication-git.ir

In the last video we walked through a second form of asynchronous communication that that was pretty

darn crazy.

Remember I did tell you at the start of the video that this pattern was going to seem really bizarre

and inefficient.

But before we entirely walk away from this pattern let's take a look at some pros and cons and get a

better idea of whether or not this is really something we want to try out.

OK.

So here's some pros and cons.

So on the plus side of this approach service D has zero dependencies on other services.

Now when I say zero dependencies I'm talking about what happens whenever a request comes into service

D can service D answer some request about what products a user has ordered without reaching out to any

other service.

The answer is yes.

Service D does not have immediate need of any other service to answer an incoming request.

It does rely upon other services to get some information to store inside this database.

But those are kind of indirect dependencies.

If SERVICE A B and C go down and they entirely disappear service D is still going to work 100 percent

correctly every single time.

And so we would say that service D it really doesn't have any other dependencies.

The other big benefit here is that service D is going to be extremely fast compared to the other two

approaches that we looked at.

And the reason for that is that service D has all the products that a user has ordered inside of and

immediately available database and so can reach into this database scraps information and immediately

respond to some request and it can do that once again without having to make a direct request to services

A B or C now about the downsides.

Well the downside here is data duplication.

We are now talking about directly duplicating data between different services.

Remember the entire key here was that whenever requests came in to sign up a user to create a product

or to purchase a product those services were going to store information about an order about a product

or that user signing up inside of its own local database.

And then we took it that information about the user thus created or the product or the order and also

stored it inside of the second database down here.

Now we did not actually store the entire record persay.

That's why back here when we spoke about really refining the requirements we said specifically the title

in the image for every product.

So product might also have information about its price its reviews all that kind of other stuff and

we're only storing the title and the image so we're not strictly 100 percent duplicating data but certainly

there is some duplication occurring here.

Now that might sound like a really bad thing because hey we're paying for some extra storage but I'm

going to come down really hard on you really hard.

If you come into the queue a discussion and you complain about paying for extra storage.

Let me tell you why right now let me put to rest any concerns about paying for extra storage.

OK we're going to a quick aside here so I did a little bit of research right now at the time on recording

this video in order to get a gigabyte worth of storage using ASR.

My Eskew L or Google cloud my ask l or eight of us.

My S Q Well it's one C eleven and a half cents on ASR.

It's 17 cents and eleven to half cents on eight of us to get one gigabyte of storage for one month.

So that's kind of a metric that's how much we have to pay for each of these providers to get one gigabyte

a storage for one month.

So I was kind of curious how much does it really cost to store the idea of some product well inside

of this blue box right here you're going to see a ton of really neat text.

So what that is right there is the API response from a W.S. or really Amazon with all the information

about some product that they are selling.

So this is the definition of a product.

According to Amazon for something they are actually selling.

So this is some pretty realistic information right here.

So it's kind of curious what does what is the size of that information.

Information for one single product.

You'll notice that this is just on data.

And so inside up here is a lot of keys and double quotes and curly braces and whatnot.

And that is all information that would normally not be stored inside the database.

But I said Yo what the heck.

Worst case scenario what is the size of that information right there.

It turns out that it's about twelve hundred bytes or so.

So we did a little calculation.

I said OK we got twelve hundred bytes or so.

That's that many gigabytes.

Times eleven a half cents per gigabyte per month.

And then I figured what would it cost to store a hundred million products that were this size inside

of some database.

And the answer is 14 dollars one hundred million products.

Fourteen dollars.

Can we afford fourteen dollars to store some extra data inside of a micro services application.

The answer is unequivocally yes.

And for extra storage.

That is not a downside because storage in the modern world is relatively free so for me data duplication.

OK.

Maybe we are going to end up with some straight stale data over time which is something that we are

going to discuss later on.

But as far as the price.

No that's that's not a cause for concern.

Period.

All right.

Now the last one here last downside hard to understand.

Yeah I would definitely say so.

This entire idea of having all of our services e-mail events and listening for events that is a lot

of overhead and that's a lot of extra code for us to write.

Lot of extra stuff to understand.

So there are some definite downsides to this approach.

But as far as providing a superior performance in uptime for our users this form of asynchronous communication

no two ways about it.

This is the way to go.

And so as you can probably guess in this course we're going to focus on this form of asynchronous communication.

We're going to create a lot of different services.

They're going to have incoming requests.

The service is going to do something locally with that request.

And if it makes a change to any data it's going to emit an event.

Other services will then wait on around listen for events to come in and eventually populate databases

that look like this right here to answer some very specific queries.

All right.

So now that we've got some idea of this form of async stuff let's take a pause right here.

We're going to start working on our first project in the next video.