We've got our full list of root handlers put together inside of our order service.
So we're now going to start to think about adding in support for events to this thing as well.
In total our order service is going to be met two kinds of events.
You might remember that we still have that EDF from a couple of videos ago when we were originally talking
about Nats.
This PDA listed out all the different events we're going to eventually publish and we had said that
the order service was going to publish events of order created and order canceled please take a look
at the reason that we are implementing both those events.
First off is order it created.
The goal of order created is to tell every other service that well in order has just been created.
Let's take a look at why each of these different services needs to know about this order being created
because it turns out that on this event we're going to have to commit a very particular piece of data
we'll start off first at the payment service the payment service needs to know that there's going to
be some kind of new order and that some user might attempt to submit some payment in the form of a credit
card or something like that.
It's a payment service needs to know about order created for two very important reasons.
First it needs to know just that there is an order that needs to be paid because eventually when a user
tries to submit that credit card they're going to also include the I.D. of the order that they are trying
to pay for.
The payments just service just needs to know hey here's some I.D. of an order and I should receive payment
for this.
But the payment service also needs to know very critically how much that order costs.
So it needs to know that it's going to receive a payment for some amount of money.
The order service or the order itself doesn't actually know about how much the order costs.
Instead it is the embedded ticket that is inside the order that is going to tell us how much the order
needs to be paid for.
That's why we are communicating this information with the payment service order created is also going
to go over to the expiration service so we can start up that 15 minute timer.
Now remember it's not necessarily 15 minutes per say.
Instead the order itself has an expiration time all ready marked on its got that expires at Flag.
So we just need to make sure that order created communicates that expiration time over to the expiration
service.
So the expiration service can eventually say after 15 minutes or however long it is.
This order should now be expired.
And then finally and this one's a little bit confusing.
The ticket service also needs to know when an order has been created.
And the reason for that is that the ticket service needs to somehow lock down a ticket and prevent editing.
So imagine the case in which an ordered go ask me a user goes to purchase a ticket when the ticket cost
twenty dollars and then maybe right after the user creates the order maybe you say two minutes after
the person who is selling the ticket goes to the ticket service and adjust the price of that ticket
to two thousand dollars.
We definitely want to prevent that from happening.
So once an order has been created and a ticket has been reserved we need to somehow make sure that a
ticket can not be edited so we're gonna do so by making sure that this order created event goes over
to the ticket service the ticket service is going to accept that event that's going to somehow lock
down a ticket from further editing until eventually the order is either paid for or cancelled that's
it for order created the other event that this thing is going to emit is order canceled.
And this one's a little bit more predictable.
So order canceled.
That's pretty much going to unreserved a ticket from the ticket service which means that the ticket
can be edited again and the person who owns the ticket can change the price of the title or whatever
else order cancel is also going to go over to the payment service.
This is just to tell the payment service that it should reject any further payments that are made for
this order.
And technically this is also going to handle refunds as well.
You'll see example that later on OK.
So that might.
Those are the two events we're going to eventually emit from the order service.
Now back inside of our Ed I just want to give you a really quick reminder on how we create events in
general inside of our common module.
We've got that S.R. C events directory so inside of here we are creating different files and these files
contain exported interfaces that describe these subjects and the data that is contained within any given
event.
So in order to implement Order cancelled and order created we pretty much just have to create two new
files inside that events directory.
Great interfaces inside them that described these subjects and the data that is going to be contained
on each of these events export them and then republish our common module and update the common module
version inside of our order service.
That's pretty much it.
So that means we'll take a pause right here and start to build out these events in just a moment.