1 00:00:01,010 --> 00:00:03,960 Are ticket service is now in a really really good place. 2 00:00:03,960 --> 00:00:08,070 We do have to still go back into the ticket service and just a little bit and add in some stuff to handle 3 00:00:08,070 --> 00:00:10,150 concurrency and a couple of other events. 4 00:00:10,200 --> 00:00:15,650 Right now we can kind of leave it in our dust so we can start to move on to our orders service. 5 00:00:15,750 --> 00:00:19,890 Now I want you to recall that this order service is all about creating an order and then eventually 6 00:00:19,890 --> 00:00:26,200 updating it and paying for it as well so we take a look at the UI or the original mockups over here. 7 00:00:26,200 --> 00:00:29,590 We've got one screen where we're going to list out all the different tickets a user is going to click 8 00:00:29,590 --> 00:00:31,910 on a ticket in order to purchase it. 9 00:00:32,080 --> 00:00:34,990 They'll be taken to a page to purchase the ticket. 10 00:00:35,050 --> 00:00:39,670 Click on that button and it will take the user to yet another page where we tell them that you have 11 00:00:39,670 --> 00:00:43,320 30 seconds or so to purchase this ticket. 12 00:00:43,320 --> 00:00:48,250 So this order service is all about keeping track of who is attempting to purchase that ticket at any 13 00:00:48,250 --> 00:00:49,450 given time. 14 00:00:49,480 --> 00:00:53,800 It's also gonna have the information that's going to lock down a ticket and not allow anyone else to 15 00:00:53,800 --> 00:00:56,920 purchase it and then eventually expire as well. 16 00:00:58,010 --> 00:01:02,920 So in total we're gonna have a couple different pieces of data inside this new order service. 17 00:01:02,960 --> 00:01:05,070 Let's first focus on just the order service itself. 18 00:01:06,010 --> 00:01:10,690 Inside the order service we're gonna have a type of record called in order and side of that order. 19 00:01:10,690 --> 00:01:16,080 We're going to store a user I.D. property that's going to be the user who is trying to purchase a ticket. 20 00:01:16,200 --> 00:01:20,320 We're gonna have a status property and that's going to describe the current status of the order. 21 00:01:20,340 --> 00:01:26,550 So whether it has expired whether it has been paid or whether it is awaiting payment we'll also make 22 00:01:26,550 --> 00:01:28,770 sure it has an expired at property. 23 00:01:28,770 --> 00:01:33,480 This is going to be essentially a timestamp that says what time this order expires. 24 00:01:34,050 --> 00:01:40,640 So it's going to essentially power that part of the UI right there once the expires time passes the 25 00:01:40,650 --> 00:01:46,470 ticket will then become unlocked and someone else will be able to purchase it The order also needs to 26 00:01:46,470 --> 00:01:52,200 know what ticket it is actually trying to lock down and the price of it as well. 27 00:01:52,230 --> 00:01:57,840 So rather than storing down or storing some ticket information directly inside the order we're going 28 00:01:57,840 --> 00:02:04,590 to instead have the order service replicate information over from the ticket service inside the order 29 00:02:04,590 --> 00:02:04,980 service. 30 00:02:04,980 --> 00:02:07,290 We will also have a collection of tickets. 31 00:02:07,450 --> 00:02:13,350 And in this collection we're going to store only the title the price and the version of the ticket so 32 00:02:13,350 --> 00:02:18,690 the order is going to store the ticket I.D. or the ticket that is trying to lock down access to and 33 00:02:18,690 --> 00:02:23,670 through that ticket I.D. we will know how much a user has to pay in order to purchase this order or 34 00:02:23,670 --> 00:02:27,960 complete the order because we're going to be able to look up a very particular ticket look at that things 35 00:02:27,960 --> 00:02:33,630 price and that's going to tell us how much the user needs to pay so because we are trying to replicate 36 00:02:33,630 --> 00:02:35,640 this ticket data which the order service. 37 00:02:35,640 --> 00:02:39,370 That means the order service needs to listen to two kinds of events. 38 00:02:39,510 --> 00:02:43,910 It's going to listen for a ticket created event coming from the ticket service and a ticket updated 39 00:02:43,920 --> 00:02:45,660 event as well. 40 00:02:45,660 --> 00:02:49,260 They'll notice on here I've got this version property on the ticket. 41 00:02:49,260 --> 00:02:54,810 You might recall that when we had been discussing concurrency issues with Nats streaming server we said 42 00:02:54,810 --> 00:02:59,190 that one way to solve that problem of events going out of order was to make use of some kind of version 43 00:02:59,190 --> 00:03:06,420 flag so just a very quick reminder here if our ticket service emits a series of events all about one 44 00:03:06,420 --> 00:03:07,740 kind of ticket being updated. 45 00:03:07,770 --> 00:03:13,880 So in this case take it with I.D. ABC we're going to first update its price to 10 20 and 30. 46 00:03:13,980 --> 00:03:19,530 We always kind of assume that these events might flow into our order service or other services in a 47 00:03:19,530 --> 00:03:20,690 very particular order. 48 00:03:20,760 --> 00:03:25,440 But as we saw we are talking about Nat streaming server it is entirely possible that these events will 49 00:03:25,440 --> 00:03:29,790 end up going over to our order service in a completely jumbled order. 50 00:03:29,790 --> 00:03:34,380 So we really can't rely upon the order of events coming into our order service correctly. 51 00:03:34,380 --> 00:03:40,680 And that's why we discussed that version property so inside the order service inside of our tickets 52 00:03:40,710 --> 00:03:45,690 collection we're going to store the version of the ticket and this version right here is going to be 53 00:03:45,690 --> 00:03:52,020 a play number that describes exactly what version of ticket this is every time we make a change to some 54 00:03:52,050 --> 00:03:53,730 attributes on the ticket itself. 55 00:03:53,730 --> 00:03:58,890 We're going to update that version number inside the ticket service the ticket service will then emit 56 00:03:58,920 --> 00:04:05,630 an event and inside that event we will print out that version number then inside of our order service 57 00:04:05,630 --> 00:04:10,100 when we receive these events we're going to reference that version number to make sure that we are processing 58 00:04:10,100 --> 00:04:13,210 these events in the correct order. 59 00:04:13,350 --> 00:04:17,220 We're not going to worry too much about this version stuff just yet until we start to get a lot of other 60 00:04:17,220 --> 00:04:19,230 stuff put together inside of our order service. 61 00:04:19,230 --> 00:04:23,220 So if you don't remember anything about that version number because we only discussed it and like one 62 00:04:23,220 --> 00:04:26,030 or two videos we never actually coded it in or anything like that. 63 00:04:26,130 --> 00:04:27,720 If you don't recall it at all totally fine. 64 00:04:27,720 --> 00:04:32,650 We're gonna have a reminder discussion about how all that stuff works in a little bit okay. 65 00:04:32,710 --> 00:04:34,430 So that is the order service. 66 00:04:34,450 --> 00:04:37,000 Long story short it's going to have orders. 67 00:04:37,030 --> 00:04:39,670 It's going to have replication of the ticket data. 68 00:04:39,670 --> 00:04:42,030 It's gonna have to listen to events from the ticket service. 69 00:04:42,130 --> 00:04:46,040 And it's also going to emit a couple of events of its own that we'll discuss in due time. 70 00:04:46,180 --> 00:04:51,460 But for right now we're going to get started on the very basics of the order service which means installing 71 00:04:51,460 --> 00:04:57,430 dependencies creating a Cuban 80s deployment file adding and routing rules and all that kind of stuff. 72 00:04:57,490 --> 00:05:01,570 So let's take a pause right here and get started on creating this new service in just a moment.