We're inside of our order created a listener.
So any time this thing gets called presumably we need to find the associated ticket and somehow lock
it down.
So in this video we're gonna figure out well how are we going to somehow lock down a ticket.
This might seem like a really obvious problem with some obvious solution.
You might say all right for all the different tickets inside of our ticket service let's add on some
kind of a locked property or something similar to that.
We'll make that a boolean and if locked is set to true that means the ticket is locked and we should
not allow anyone to make any changes to it.
And then whenever we see the order canceled event we can flip locked back over to false.
Which means now people can edit his ticket once again.
This seems like a pretty obvious straightforward solution that a doubt but I could suggest maybe if
we start to think forward a little bit about some other capabilities that we're going to maybe eventually
want to have inside our application we will realize that just having a simple boolean maybe not the
best thing in the world so I want you to imagine the following scenario if we made use of some simple
boolean to track whether or not a ticket is locked.
Let's imagine that some user who actually owns this ticket.
So this is the person who is trying to sell this ticket.
Once you figure out what the status of their ticket is they might make some kind of request to our ticket
service asking Is someone buying my ticket.
Is this thing getting sold.
What is the state of the ticket if we were only recording this locked flag right here as true or false.
Then we can really only say something like this as a response.
We can probably say yes the tickets locked.
Which means it's being purchased but we have no idea who is purchasing it.
No clue what so whatsoever and that probably would not be a great response to come back to some one
who is ordering the ticket.
Imagine if you were selling something and you were selling it through some Web site and you want to
find out what the status of your thing that you're selling is.
And the website just told you.
Yeah we think someone's buying it but we've got no idea what's going on with that transaction whatsoever.
Not a great response.
So rather than just recording this very simple flag right here of locked.
True or false.
We're going to instead record the order I.D. that is tied to the ticket.
So this is going to be the order.
Just the idea of it that is somehow reserving this ticket.
And once you have that information getting some information about the status the ticket is going to
be a lot more straightforward.
Now someone who owns a ticket can make a request and say Is someone buying my ticket and will send back
some response that says yeah someone is buying it and the order I.D. that represents the person who
is trying to buy the thing is maybe less than this person who owns the ticket could make a followup
request overture order service and very easily say what is the status of order.
Yes and maybe it is currently awaiting payment so we could send that back to the user and say yeah we're
just waiting for someone to pay for the thing and then you'll get your money from the ticket being sold
but this is a little bit more kind of forward thinking approach even though it is a little bit greater
complexity now a little bit of specifics here.
We're going to use the presence of an order I.D. to decide whether or not a ticket is currently reserved.
And so whether or not we should prevent edits to it by default all tickets will be created with a null
value for order I.D. So if there is no order I.D..
That means that the ticket is not reserved and we should allow edits but as soon as there is an order
I.D. Now the thing should be locked prevent edits.
The other thing I want to mention very quickly in passing here is technically the order I.D. is not
strictly necessary to look up the status of some order that is tied to a ticket.
Technically we could just take this ticket idea right here and maybe create a new endpoint inside of
our order service to take a ticket I.D. and return some information about the order that is associated
with that ticket because the order service does know all these different ticket ideas that would definitely
a possibility but we don't actually have a root handler for that right now.
We would have to build out some separate functionality to say hey give us a ticket idea we'll find the
appropriate order associated with that thing if it actually exists.
If we instead just make use of this order I.D. system keep track of the audience that ticket service
then we can actually reuse some existing code that we already have inside the order service.
We already have a root handler that is setup to return a order given an I.D. that's already been put
together and so it would be really easy to reuse that code as opposed to have to write an entirely new
endpoint to retrieve an order based upon a ticket ideologue OK.
That's it.
That's how we're going to lock down a ticket.
So what does that really mean in practice.
Well it means that inside of on message I here whenever we are told that an order has been created we're
going to take out of this event right here and if we forget what is actually defined in it we always
do that comment click so the idea right here is the idea the order that was created and more importantly
we've also got the information about the ticket those create as well.
Specifically the ideas.
So instead of on message we're going to take that I.D. instead of on message.
We're then going to use that to fetch some ticket out of our tickets collection.
And then on the ticket model or ticket document we're going to store the order I.D. from also inside
this order created events so we're going to store that order I.D. inside of the ticket in our ticket
service.
Well we're also going to have to open up our models ticket to us file and just make sure that we add
in the idea of a ticket having an order idea property.
So in total we're going to make a quick change the ticket model file and then write out some logic inside
the order creating listener.
And that's pretty much it that's now that we've got a overview on what's going on here.
Let's start the implementation in the next video.