Our order created listeners is looking pretty good and we've got some tests around it.
So that's it.
Right.
We're all done with the listener.
Well come on you know by now.
No we're not done with the listener.
Turns out there's a hidden little issue inside of here.
Something that could very easily bite us if we deployed this code as it stands right now.
So let's take a look at a diagram and understand a little mistake we have inside of here OK.
So we're going to take a look at a series of diagrams that's going to walk you through a potential flow
inside of our app.
And we're going to see inside of this very specific series of actions we eventually end up with some
pretty darn inconsistent data so we're going to begin by imagining that inside of our order service
we have replicated over a ticket.
This is a ticket that is defined inside the order service.
And we want to reserve it naturally to reserve a ticket.
We're going to create an order.
And whenever we create an order right now we are emitting an order created event.
So this is an event that is going to be sent from the order service over to the ticket service to tell
the ticket service that this ticket is being reserved because we just created in order so this event
right here is going to say that our ticket I.D. sees you that's this one right here we have created
in order to reserve it and that order has an I.D. of 80 s to the ticket service specifically the ticket
service listener I mean the order created listener inside of there is going to find the relevant ticket.
It's going to take that orders idea of 80 s and update the order I.D. property.
Also remember that anytime that we make a change to a record that Mongoose update if current module
is going to automatically increment the version number.
And so we would go to version number one.
Like so get let's out consider a next possible step something that could definitely happen inside of
rap at some point in the future after this event at some point in the future maybe the user decides
not to purchase this ticket.
Maybe they don't pay the ticket in time or pay the order in time or whatever it is.
But at some point time in the future we can imagine that maybe we get an order canceled event coming
from the order service as well.
We have not implemented this event yet but I'm sure you can imagine what this event is going to do to
our ticket service whenever we see order canceled.
We want to unreserved this ticket.
So we would find the ticket with IDC Q That's this one right here and we would remove that order I.D.
It is the presence of the order I.D. that indicates whether or not a ticket is reserved or canceled
means don't want to reserve the ticket anymore.
So we would just remove the order items property also because we are making a change to this ticket
we would increment its version to 2 Okay.
So now next possible step let's imagine that now that the ticket is unlocked and unreserved maybe the
person who owns this ticket decides you know what I want to change the price so they make a request
to edit the ticket and they want to change the price to 30.
This is something we have totally built into our application.
Definitely not outside the realm of possibility to have this happen.
So we would find the ticket with Susie Q updated price to 30 and once again because we are making a
change to this ticket.
The Mongoose update if current module would automatically increment the version here to 3.
Now do you remember as well that when the anytime we make a change to a ticket whenever we change the
price through the request handler of ticket EDIT We also emit an event just to describe the fact that
we have changed this price and so we can really imagine and simultaneously right after making that change
we would emit an event that looks something like this.
We would say for ticket i.e. Susie Q We have changed its price to 30 and the current version of this
event or this ticket is version 3.
So what do we do at this event.
Well remember right now this event is going to go over to our order service because we want to keep
all the data all the tickets between these two services in sync.
So this event will go over to the order service.
We're going to process it and update the order services copy of this ticket there's just one little
issue with that so here's the same diagram I've just added in the order service at the very bottom and
the issue here is that if we take a look at this ticket it still has a version of zero right now the
initial version of that ticket.
So it turns out that when we had made those updates through order it created an order canceled.
We made changes to this ticket but we and we increment to the version but we never kind of percolated
those changes so to speak or emitted some event to describe these changes and got that picked up by
our order service as far as the order service is concerned.
We have a ticket right here of version zero the order service is going to see an incoming event with
a version of three and the order service is going to say oh I can't process this event just yet.
It has a version of three and I'm stuck on version zero.
So the order service is going to assume that it must be missing two events the event with version 1
and the event with version 2 so the obvious solution here very plain and clear.
It's just that whenever we make any kind of change that ticket through say the order created event listener
or order canceled which we're going to put together in a little bit we have to emit an event.
We just have to emit an event and say hey here's some new version so that all the dependent services
can update their data and update that version number as well.
Otherwise the version numbers are going to fall out of sync and we're not going to or as soon as we
start to emit another event around this record all these dependent services are going to say oh I must
be missing some events I'm going to reject this one and wait for those other events going to come in
even though we had never emitted them so again the real lesson here is just whenever we make a change
to a record we have to emit any event.
So that might I think the path forward is pretty clear inside of our order create a listener.
We are making a change to our ticket and because we are making a change we just have to emit any event
that's pretty much it.
Let's take a quick pause right here come back the next video add in some code to emit an event right
after we change that ticket to just say hey this ticket spend change so quick pause I'll see you in
just a minute.