All language subtitles for 010-A Crazy Way of Storing Data-git.ir

We've now seen how to communicate between different services using synchronous and asynchronous communication.

We're now going to take a look at a second way of using asynchronous communication.

Now I gotta tell you right now that the second way that we're gonna look at it is going to be a little

bit similar to the database for service pattern in that this stuff is going to seem really bizarre and

pretty and efficient but just bear with me.

We're going to go through a pretty deep example to give you an idea of how we're going to use asynchronous

communication to somehow communicate between these different services.

We're going to once again focus on this idea of introducing service D into our e commerce application

that just has three existing services.

The first thing I want to do is to put a better goal or really define exactly what we want service D

to do.

Right now we're just saying oh yeah we're going to show products ordered by a particular user but I

want to be really explicit in saying here are the inputs to the service.

And here is what is expected to respond with whenever it receives a request.

So here's my more exact definition of what service D is supposed to do.

I'm going to say that given the idea of a user I want to show the title and image for every product

that they have ever ordered.

That's the exact precise goal of service D.

Now with that in mind let's try to imagine creating a database that would serve this goal right here

really well.

So here's my idea of how we could add in a database to service D to solve this little feature request.

So I think that we could introduce a database it could be no sequel or sequel based doesn't really matter

with two separate collections of data.

One would be a record of all the different users who have signed up to our application.

We don't really care about a user's email address.

We don't care about their name.

We don't care about their age or address.

The only thing we said for our service as an input is that we need to know the idea of a user and then

show products that they have ordered.

So inside of this user's collection I would record the I.D. of every user who signs up to my app and

on the I.D. of any products they ever order.

And then to actually know what the title and images for every product I could have a separate collection

of products where I record the idea the product its title and its image.

So if I put in some practical data here I might end up with something like this maybe I would have an

I.D. of five and 20 or some products and I would have a title of say pants and shoes and an image of

pants dot j peg and shoes deejay peg and then maybe if some user came along and ordered some product

maybe they have an idea of one.

That's the idea my user and if they ordered products 5 and 20 I could store those inside of an array

like so.

So now can we answer this question.

Can we fulfill this feature using this database.

Well let's walk through it again.

So if I have the idea of a user let's say that's user at one I need to show the title an image for every

product I have ever ordered.

OK.

So we would go into our users collection we'd find the user tidy one we'd find that the product ideas

they have ordered are five and 20.

So we'd then go and look inside of our products collection.

We would find a product with five and 20.

Look at the appropriate title and image for both and then respond with both those to some incoming requests

to service D.

Well it seems like that solves the issue.

So if we had a database with this structure right here we could implement service D very easily.

And what's more service D would be 100 percent self-contained.

So this really turns into a question of how can we create this database and stick in the relevant information

inside there.

That is the challenge in its own right.

And the reason for that is that if we think about the overall structure of our application right now

service D is never really going to be told about whenever a user signs up whenever a product gets created

or whenever a user orders a given product because that information is being sent in requests to service

a b and c and in output from all that is never making its way over to service D.

So right now it would be kind of hard to get any relevant information into this database that we just

imagined.

So that's what we need to solve.

We need to think how we can tell get service A B and C to somehow tell service D about anytime a user

signs up product is created or a user orders a product.

And what's more whenever service a b and c communicates that over we need to figure out how to do that

communication in some kind of way where service a isn't going to fail if service D is not up.

So in other words if we tried to use some synchronous communication to have service a tell service deal

whenever user signs up.

Well once again that's a dependency if that request failed for some reason.

Who knows service they might crash as well.

That's all of our requirements put together.

So how are we going to solve this.

Well that's going to come down to that form of asynchronous communication.

So let's go through this process so we're going to imagine the workflow of how we would get information

into our database right here.

Here is exactly what would happen any time a request comes in to create a product to sign up a user

or to create a or purchase a product create an order.

We're going to have these relevant services emit an event simultaneously describing what just happened

to them.

Let me show you what I mean.

Let's first imagine that we boot up our application for the very first time and we decide to go into

our app and create a couple of different products so maybe we make a request a service be but the goal

of creating a product internally service B would say OK I got this request I'm going to create a product

and save it into my personal database simultaneously.

And here's the key service B would also emit an event over to our service bus and that event might look

a little something like this.

Let me zoom in so you can see this more easily so service B right after saving that new product might

event emit an event that says hey everybody if anyone cares a product was just created and here are

some details about that product maybe it has an I.D. title and an image.

So that event would flow into our event broker over here.

Here's the event bus or event broker event bus would then it take that event and send it off to any

interested services.

So in this case that would be service D a service D would receive this event we would have some code

inside there to receive this event and service D would say OK a product was created as an idea of one

idea pants an image of pants dot j peg.

So service D would take that information and record that event inside of its products table.

So it put in say idea of one dollar pants and pants dot j peg so that's how we would start to get some

information into this database.

We are going to rely upon these other services A B and C emitting events.

Anytime something interesting occurs let's now go through the same process and imagine what would happen

whenever a user signs up to our application so let's imagine a little bit later after we create that

product and I'll update some terminology here.

There we go so maybe a little bit later a user comes and signs up to our application so we get a request

to sign up.

That would come into our service a service a would create a new user inside of its users collection

and then it would emit an event over to this event bus and maybe it would look something like type of

user created and maybe add some data it would have just the idea of the user that was created.

So once again this event would flow over to the event bus the event bus would send that event along

to service d down here inside of service D we would have some code to interpret this event you would

say OK a user was just created.

Well I'm going to save them as a user to my users collection but put down an idea one.

And right now this user has not ordered any products sort of maybe just put in an empty array of product

ideas.

Now I think you can understand where this is going down the last step.

We would imagine really quickly that we get a request to order a product

so that would go to service see I won't change any terminology on this little thing right here just

to save time.

We'd say that requested come into service C service C would say OK I'll create a new order inside of

some collection and then you met an event and maybe that event would look something like order created

and it might have some information tied to it like the idea of the user and the idea of the product

that was created as well so we would have that event flow off to our event bus that would come into

our service D over here once again service D could say OK order was created.

It looks like user of I.D. one ordered a product without one.

So it would update this products idea array right there but in the one and there we go we've now got

our database fully populated and service D can instantly very quickly answer the question what products

has a user with I.D. number one ordered OK.

So that is asynchronous communication that kind of second form that we're going to look at.

That's been a very long video so you can take a pause right here and then do a summary and talk about

some pros and cons of this approach in the next video.