Are ticket service is now in a really really good place.
We do have to still go back into the ticket service and just a little bit and add in some stuff to handle
concurrency and a couple of other events.
Right now we can kind of leave it in our dust so we can start to move on to our orders service.
Now I want you to recall that this order service is all about creating an order and then eventually
updating it and paying for it as well so we take a look at the UI or the original mockups over here.
We've got one screen where we're going to list out all the different tickets a user is going to click
on a ticket in order to purchase it.
They'll be taken to a page to purchase the ticket.
Click on that button and it will take the user to yet another page where we tell them that you have
30 seconds or so to purchase this ticket.
So this order service is all about keeping track of who is attempting to purchase that ticket at any
given time.
It's also gonna have the information that's going to lock down a ticket and not allow anyone else to
purchase it and then eventually expire as well.
So in total we're gonna have a couple different pieces of data inside this new order service.
Let's first focus on just the order service itself.
Inside the order service we're gonna have a type of record called in order and side of that order.
We're going to store a user I.D. property that's going to be the user who is trying to purchase a ticket.
We're gonna have a status property and that's going to describe the current status of the order.
So whether it has expired whether it has been paid or whether it is awaiting payment we'll also make
sure it has an expired at property.
This is going to be essentially a timestamp that says what time this order expires.
So it's going to essentially power that part of the UI right there once the expires time passes the
ticket will then become unlocked and someone else will be able to purchase it The order also needs to
know what ticket it is actually trying to lock down and the price of it as well.
So rather than storing down or storing some ticket information directly inside the order we're going
to instead have the order service replicate information over from the ticket service inside the order
service.
We will also have a collection of tickets.
And in this collection we're going to store only the title the price and the version of the ticket so
the order is going to store the ticket I.D. or the ticket that is trying to lock down access to and
through that ticket I.D. we will know how much a user has to pay in order to purchase this order or
complete the order because we're going to be able to look up a very particular ticket look at that things
price and that's going to tell us how much the user needs to pay so because we are trying to replicate
this ticket data which the order service.
That means the order service needs to listen to two kinds of events.
It's going to listen for a ticket created event coming from the ticket service and a ticket updated
event as well.
They'll notice on here I've got this version property on the ticket.
You might recall that when we had been discussing concurrency issues with Nats streaming server we said
that one way to solve that problem of events going out of order was to make use of some kind of version
flag so just a very quick reminder here if our ticket service emits a series of events all about one
kind of ticket being updated.
So in this case take it with I.D. ABC we're going to first update its price to 10 20 and 30.
We always kind of assume that these events might flow into our order service or other services in a
very particular order.
But as we saw we are talking about Nat streaming server it is entirely possible that these events will
end up going over to our order service in a completely jumbled order.
So we really can't rely upon the order of events coming into our order service correctly.
And that's why we discussed that version property so inside the order service inside of our tickets
collection we're going to store the version of the ticket and this version right here is going to be
a play number that describes exactly what version of ticket this is every time we make a change to some
attributes on the ticket itself.
We're going to update that version number inside the ticket service the ticket service will then emit
an event and inside that event we will print out that version number then inside of our order service
when we receive these events we're going to reference that version number to make sure that we are processing
these events in the correct order.
We're not going to worry too much about this version stuff just yet until we start to get a lot of other
stuff put together inside of our order service.
So if you don't remember anything about that version number because we only discussed it and like one
or two videos we never actually coded it in or anything like that.
If you don't recall it at all totally fine.
We're gonna have a reminder discussion about how all that stuff works in a little bit okay.
So that is the order service.
Long story short it's going to have orders.
It's going to have replication of the ticket data.
It's gonna have to listen to events from the ticket service.
And it's also going to emit a couple of events of its own that we'll discuss in due time.
But for right now we're going to get started on the very basics of the order service which means installing
dependencies creating a Cuban 80s deployment file adding and routing rules and all that kind of stuff.
So let's take a pause right here and get started on creating this new service in just a moment.