At the end of the last video I said that all this last transaction no stuff around the transaction service
was going to work somewhat similarly for our ticketing application as well.
Specifically the tickets service.
So we had just been working on a little bit ago.
I said that we were going to see how this stuff worked with the ticket service later on but I realized
it probably made a lot more sense to just show you how all this idea of the last transaction number
or a version number of sorts is going to work with our ticketing application right away.
While all this stuff is still fresh in our minds.
So quick example here of how this stuff is going to work with our tickets service so we're gonna follow
the exact same pattern we saw in this diagram back over here.
We're going to assume a request is going to come in to the service that owns that resource.
We're going to save that resource and then you met an event describing that change.
Now once service in our application that really cares about the price of a ticket is the orders service
in the orders database.
We haven't worked on the order service just yet but for right now just understand that the order service
is going to need to know the price of every single ticket.
And it's also you need to know anytime that price changes as well.
So we're going to imagine that a request is going to come into our ticket service to first create a
ticket and then update that ticket over time and we're going to imagine what would happen if there is
some issue with the ordering of these events that are going to be issued from creating and then updating
the ticket.
First off well let's imagine what happens when we make these requests the request number one we're going
to try to create the ticket with a price of ten dollars that will flow in we'll process that and we'll
make an update to our tickets database.
We're going to say that the ticket that we create is going to have an idea of C.C. Q an initial price
of ten and then very similar to that transaction or last transaction number something we had.
Whenever we create a ticket we're going to apply a version number to this thing as well so we're gonna
say that this is version 1 of this record.
Well then you met an event that write out over here so it'll probably have a name of something like
a ticket created and then inside the event will provide the idea the ticket sees.
Q The price of 10 and the version number as well.
And so that will presumably be sent off immediately over to our Net server and then that event will
show up inside of our order service.
Well let's imagine that before that event is even emitted maybe the user instantaneously follows up
with two additional requests to change the ticket price and very very quick succession so we're going
to imagine instantly after creating this ticket the user then submits a request to update the price
of its we're going to say fine ticket Susie Q Instead it's price to 50 dollars.
So we will process that change inside of our database change the price to 50 and then as soon as we
make any change whatsoever to this record we're going to increment that version number.
So because we just change this price will now increment its version number two to and then just as we
saw previously will then fabricate an event describing the change we just made.
So we'll give this a type of something like ticket updated an idea of Caesar.
Q It's new price and we'll also put on there the version as well.
So now it's version 2.
I think you can see where this is going.
So we're not going to have the last requests come in a very short order a fine ticket.
Q updated price to one hundred.
Very good.
Well then automatically update the version because we made a change to this record and now we'll also
admit any event of ticket updated idea of season Q price is now one hundred and version is three okay.
So now we're going to imagine that these events get thrown off to that streaming server.
Of course they're going to be handled or thrown over to Nats one at a time.
So in other words with the first request as soon as possible we're gonna throw that event over again
with the second request.
Little bit later it will then be that one and then the third one and we can imagine that these all get
thrown over sequentially in the correct order.
But just for the sake of this diagram let's imagine they all just kind of show up in a big batch to
that streaming server so then we want to process these events inside of our order service because like
I said the order service needs to know the exact price of a ticket at any given time so let's imagine
that these events get processed possibly very much out of order.
So once again maybe the first event upgrading the ticket goes to service a for instance say and then
the first update goes to B.
And once again we'll assume that this request right here or this event to create the ticket is fails
for whatever reason.
So we're going to wait 30 seconds for that thing to be processed so I can throw it back over by Nats
and it's eventually after 30 seconds going to be sent back over to one of our order service instances.
Now this order service B has received this event and it's saying update the ticket.
Well at this point time we don't have anything inside of our database about this ticket so we might
write out some code inside there to say try to find this ticket if we can't find a ticket with the I.D.
C.C. q then just don't acknowledge the event maybe throw an error for logging purposes and just don't
acknowledge it.
So then after 30 seconds this thing's going to time out.
So again we'll imagine it goes back over to our NAT server.
All right after 30 seconds of fast we're not gonna give it a shot at processing a ticket created once
again so ticket created.
Well let's go and create the ticket.
So let's take an idea of Caesar.
A price of 10.
In a version of one.
So that's it.
We've now processed that event.
We can acknowledge it.
And we essentially forget it ever happened.
So now we need to process the second event and a third event.
Let's now say the second one goes over to the listener a.
And this third one goes to be once again.
Let's assume that something goes wrong with processing.
Number two right here.
So that thing is gonna eventually time out after 30 seconds and now B right here is going to try to
process this event.
So in this case we are going to write code inside of our order service to say find ticket Caesar.
Q Take a look at its version and only update this thing if the version of the record saved in our database
is equal to two because we are trying to apply.
UPDATE 3 that means version 2 must have already been applied to process this update.
So in this case we would find ticket Caesar Q we'd see that its version is one which means we have not
yet processed too.
So once again we get through an error.
We can log something at any rate we are not going to acknowledge this message we're going to allow this
thing to time out and hopefully eventually be read liver to one of our services so then after 30 seconds
or so NATS is gonna try to re deliver a ticket or event to we'll find Caesar.
Q Okay the version we have in our database is one we have an update record right here for two awesome
everything lines up.
So update to 2 the price is going to go to 50 and we are happy campers and after some point time we're
gonna get this third one.
OK fine season.
Q There it is.
We have version 2.
We're getting a update to go to version 3 awesome everything lines up we'll update that update.
The price to one hundred and once again we're good to go so that's exactly what we're gonna do in our
application.
All we have to do is add in this little version flag we're going to add it to the service that is the
canonical service that manages any given resource.
So if we're talking about tickets or tickets service is going to manage this version flag.
This is gonna be the only location where the version is ever going to be directly updated everywhere
else.
So every other service that depends upon processing updates in response to this record is never going
to lead the ticket service.
In other words we would never ever expect the order database to somehow have a version of four while
the ticket database is still at a version of three so every other service because that these other services
are not the ones directly in charge or directly responsible the definition of a ticket will always have
an equal or lagging version for this record.
And again we're only ever going to increment it on this primary service that manages this resource whenever
we make a change to one of the attributes inside of here now.
Quick note if managing this version stuff sounds really daunting.
Absolutely do not sweat it turns out that Mongo D.B. and Mongoose actually have a lot of stuff built
in to handle this versioning stuff for us.
The only reason we're going through all this discussion is that you understand what this version stuff
is for.
It turns out that when we go to implement it it's actually gonna be really easy and straightforward
but it's going to handle just about every conceivable scenario where we might throw some events at these
order services or whatever else and the service crashes or times out where the database isn't available
or not sends it to a service that isn't actually running and so on.
The only thing that we really have to worry about here and it is something we'll discuss later on is
the case in which we try to process some event and we just repeatedly repeatedly fail it over and over
again because it is for some reason completely unprocessed on processing all.
And that's something we will discuss later on.
But for any kind of transient failure like a broken connection or something like that or we're getting
events out of order this process this idea of versioning is always going to fix it.
Okay.
I apologize for the beginning of time for these long videos but I'm just trying to do the biggest knowledge
dump I can.
We're pretty much at the dawn are all done with all this kind of theory stuff.
So now for real we can take a pause go back to the next video we're going to add in just a little bit
more code to get understanding of this one last big feature in that's and then we'll be able to start
implementing all this eventing stuff inside of application.
OK.
Quick buzz see in a minute.