1 00:00:00,630 --> 00:00:06,180 At the end of the last video I said that all this last transaction no stuff around the transaction service 2 00:00:06,240 --> 00:00:09,300 was going to work somewhat similarly for our ticketing application as well. 3 00:00:09,330 --> 00:00:11,150 Specifically the tickets service. 4 00:00:11,160 --> 00:00:13,210 So we had just been working on a little bit ago. 5 00:00:13,440 --> 00:00:17,760 I said that we were going to see how this stuff worked with the ticket service later on but I realized 6 00:00:17,790 --> 00:00:22,500 it probably made a lot more sense to just show you how all this idea of the last transaction number 7 00:00:22,500 --> 00:00:26,160 or a version number of sorts is going to work with our ticketing application right away. 8 00:00:26,160 --> 00:00:28,280 While all this stuff is still fresh in our minds. 9 00:00:28,470 --> 00:00:34,220 So quick example here of how this stuff is going to work with our tickets service so we're gonna follow 10 00:00:34,250 --> 00:00:37,490 the exact same pattern we saw in this diagram back over here. 11 00:00:37,490 --> 00:00:41,230 We're going to assume a request is going to come in to the service that owns that resource. 12 00:00:41,360 --> 00:00:46,460 We're going to save that resource and then you met an event describing that change. 13 00:00:46,580 --> 00:00:52,310 Now once service in our application that really cares about the price of a ticket is the orders service 14 00:00:52,310 --> 00:00:53,630 in the orders database. 15 00:00:53,720 --> 00:00:58,220 We haven't worked on the order service just yet but for right now just understand that the order service 16 00:00:58,220 --> 00:01:01,490 is going to need to know the price of every single ticket. 17 00:01:01,490 --> 00:01:05,040 And it's also you need to know anytime that price changes as well. 18 00:01:05,330 --> 00:01:09,440 So we're going to imagine that a request is going to come into our ticket service to first create a 19 00:01:09,440 --> 00:01:14,450 ticket and then update that ticket over time and we're going to imagine what would happen if there is 20 00:01:14,450 --> 00:01:19,670 some issue with the ordering of these events that are going to be issued from creating and then updating 21 00:01:19,670 --> 00:01:20,590 the ticket. 22 00:01:20,720 --> 00:01:25,970 First off well let's imagine what happens when we make these requests the request number one we're going 23 00:01:25,970 --> 00:01:30,770 to try to create the ticket with a price of ten dollars that will flow in we'll process that and we'll 24 00:01:30,770 --> 00:01:32,930 make an update to our tickets database. 25 00:01:32,930 --> 00:01:38,910 We're going to say that the ticket that we create is going to have an idea of C.C. Q an initial price 26 00:01:38,910 --> 00:01:43,960 of ten and then very similar to that transaction or last transaction number something we had. 27 00:01:44,100 --> 00:01:48,960 Whenever we create a ticket we're going to apply a version number to this thing as well so we're gonna 28 00:01:48,960 --> 00:01:52,650 say that this is version 1 of this record. 29 00:01:52,880 --> 00:01:59,370 Well then you met an event that write out over here so it'll probably have a name of something like 30 00:01:59,370 --> 00:02:04,220 a ticket created and then inside the event will provide the idea the ticket sees. 31 00:02:04,230 --> 00:02:08,430 Q The price of 10 and the version number as well. 32 00:02:10,300 --> 00:02:15,470 And so that will presumably be sent off immediately over to our Net server and then that event will 33 00:02:15,470 --> 00:02:17,380 show up inside of our order service. 34 00:02:17,380 --> 00:02:22,820 Well let's imagine that before that event is even emitted maybe the user instantaneously follows up 35 00:02:22,820 --> 00:02:29,610 with two additional requests to change the ticket price and very very quick succession so we're going 36 00:02:29,610 --> 00:02:33,720 to imagine instantly after creating this ticket the user then submits a request to update the price 37 00:02:33,720 --> 00:02:39,240 of its we're going to say fine ticket Susie Q Instead it's price to 50 dollars. 38 00:02:39,450 --> 00:02:44,010 So we will process that change inside of our database change the price to 50 and then as soon as we 39 00:02:44,010 --> 00:02:48,460 make any change whatsoever to this record we're going to increment that version number. 40 00:02:48,590 --> 00:02:54,710 So because we just change this price will now increment its version number two to and then just as we 41 00:02:54,710 --> 00:03:01,270 saw previously will then fabricate an event describing the change we just made. 42 00:03:01,410 --> 00:03:05,430 So we'll give this a type of something like ticket updated an idea of Caesar. 43 00:03:05,440 --> 00:03:09,970 Q It's new price and we'll also put on there the version as well. 44 00:03:10,050 --> 00:03:11,440 So now it's version 2. 45 00:03:11,460 --> 00:03:13,040 I think you can see where this is going. 46 00:03:13,140 --> 00:03:18,050 So we're not going to have the last requests come in a very short order a fine ticket. 47 00:03:18,050 --> 00:03:20,030 Q updated price to one hundred. 48 00:03:20,090 --> 00:03:20,870 Very good. 49 00:03:20,870 --> 00:03:26,350 Well then automatically update the version because we made a change to this record and now we'll also 50 00:03:26,370 --> 00:03:38,330 admit any event of ticket updated idea of season Q price is now one hundred and version is three okay. 51 00:03:38,350 --> 00:03:41,580 So now we're going to imagine that these events get thrown off to that streaming server. 52 00:03:41,580 --> 00:03:45,340 Of course they're going to be handled or thrown over to Nats one at a time. 53 00:03:45,390 --> 00:03:49,770 So in other words with the first request as soon as possible we're gonna throw that event over again 54 00:03:49,800 --> 00:03:50,910 with the second request. 55 00:03:50,940 --> 00:03:55,440 Little bit later it will then be that one and then the third one and we can imagine that these all get 56 00:03:55,440 --> 00:03:57,650 thrown over sequentially in the correct order. 57 00:03:57,750 --> 00:04:02,090 But just for the sake of this diagram let's imagine they all just kind of show up in a big batch to 58 00:04:02,090 --> 00:04:07,840 that streaming server so then we want to process these events inside of our order service because like 59 00:04:07,840 --> 00:04:14,000 I said the order service needs to know the exact price of a ticket at any given time so let's imagine 60 00:04:14,210 --> 00:04:17,870 that these events get processed possibly very much out of order. 61 00:04:17,870 --> 00:04:24,280 So once again maybe the first event upgrading the ticket goes to service a for instance say and then 62 00:04:24,340 --> 00:04:26,140 the first update goes to B. 63 00:04:26,140 --> 00:04:32,050 And once again we'll assume that this request right here or this event to create the ticket is fails 64 00:04:32,050 --> 00:04:32,880 for whatever reason. 65 00:04:33,160 --> 00:04:37,240 So we're going to wait 30 seconds for that thing to be processed so I can throw it back over by Nats 66 00:04:37,300 --> 00:04:42,880 and it's eventually after 30 seconds going to be sent back over to one of our order service instances. 67 00:04:42,910 --> 00:04:47,600 Now this order service B has received this event and it's saying update the ticket. 68 00:04:47,640 --> 00:04:52,690 Well at this point time we don't have anything inside of our database about this ticket so we might 69 00:04:52,690 --> 00:04:56,980 write out some code inside there to say try to find this ticket if we can't find a ticket with the I.D. 70 00:04:56,990 --> 00:05:02,560 C.C. q then just don't acknowledge the event maybe throw an error for logging purposes and just don't 71 00:05:02,560 --> 00:05:03,670 acknowledge it. 72 00:05:03,670 --> 00:05:06,460 So then after 30 seconds this thing's going to time out. 73 00:05:06,460 --> 00:05:12,300 So again we'll imagine it goes back over to our NAT server. 74 00:05:12,390 --> 00:05:16,770 All right after 30 seconds of fast we're not gonna give it a shot at processing a ticket created once 75 00:05:16,770 --> 00:05:19,110 again so ticket created. 76 00:05:19,110 --> 00:05:20,490 Well let's go and create the ticket. 77 00:05:20,520 --> 00:05:22,240 So let's take an idea of Caesar. 78 00:05:23,510 --> 00:05:24,640 A price of 10. 79 00:05:24,680 --> 00:05:26,200 In a version of one. 80 00:05:26,450 --> 00:05:26,930 So that's it. 81 00:05:26,930 --> 00:05:28,970 We've now processed that event. 82 00:05:28,970 --> 00:05:30,080 We can acknowledge it. 83 00:05:30,260 --> 00:05:33,620 And we essentially forget it ever happened. 84 00:05:33,630 --> 00:05:37,650 So now we need to process the second event and a third event. 85 00:05:38,090 --> 00:05:41,360 Let's now say the second one goes over to the listener a. 86 00:05:41,580 --> 00:05:45,620 And this third one goes to be once again. 87 00:05:45,660 --> 00:05:48,050 Let's assume that something goes wrong with processing. 88 00:05:48,090 --> 00:05:49,360 Number two right here. 89 00:05:49,380 --> 00:05:54,180 So that thing is gonna eventually time out after 30 seconds and now B right here is going to try to 90 00:05:54,180 --> 00:05:55,590 process this event. 91 00:05:55,590 --> 00:06:00,660 So in this case we are going to write code inside of our order service to say find ticket Caesar. 92 00:06:00,670 --> 00:06:08,010 Q Take a look at its version and only update this thing if the version of the record saved in our database 93 00:06:08,160 --> 00:06:10,490 is equal to two because we are trying to apply. 94 00:06:10,520 --> 00:06:15,860 UPDATE 3 that means version 2 must have already been applied to process this update. 95 00:06:15,870 --> 00:06:21,390 So in this case we would find ticket Caesar Q we'd see that its version is one which means we have not 96 00:06:21,390 --> 00:06:22,410 yet processed too. 97 00:06:22,410 --> 00:06:23,970 So once again we get through an error. 98 00:06:23,970 --> 00:06:29,430 We can log something at any rate we are not going to acknowledge this message we're going to allow this 99 00:06:29,430 --> 00:06:36,150 thing to time out and hopefully eventually be read liver to one of our services so then after 30 seconds 100 00:06:36,150 --> 00:06:42,000 or so NATS is gonna try to re deliver a ticket or event to we'll find Caesar. 101 00:06:42,000 --> 00:06:48,180 Q Okay the version we have in our database is one we have an update record right here for two awesome 102 00:06:48,180 --> 00:06:48,930 everything lines up. 103 00:06:49,380 --> 00:06:55,080 So update to 2 the price is going to go to 50 and we are happy campers and after some point time we're 104 00:06:55,080 --> 00:06:56,510 gonna get this third one. 105 00:06:56,660 --> 00:06:57,720 OK fine season. 106 00:06:57,720 --> 00:06:59,130 Q There it is. 107 00:06:59,130 --> 00:07:00,430 We have version 2. 108 00:07:00,570 --> 00:07:05,550 We're getting a update to go to version 3 awesome everything lines up we'll update that update. 109 00:07:05,580 --> 00:07:11,130 The price to one hundred and once again we're good to go so that's exactly what we're gonna do in our 110 00:07:11,130 --> 00:07:11,880 application. 111 00:07:11,880 --> 00:07:16,590 All we have to do is add in this little version flag we're going to add it to the service that is the 112 00:07:16,620 --> 00:07:20,130 canonical service that manages any given resource. 113 00:07:20,130 --> 00:07:25,230 So if we're talking about tickets or tickets service is going to manage this version flag. 114 00:07:25,230 --> 00:07:31,110 This is gonna be the only location where the version is ever going to be directly updated everywhere 115 00:07:31,110 --> 00:07:31,530 else. 116 00:07:31,530 --> 00:07:37,440 So every other service that depends upon processing updates in response to this record is never going 117 00:07:37,440 --> 00:07:39,050 to lead the ticket service. 118 00:07:39,050 --> 00:07:43,710 In other words we would never ever expect the order database to somehow have a version of four while 119 00:07:43,710 --> 00:07:50,960 the ticket database is still at a version of three so every other service because that these other services 120 00:07:50,960 --> 00:07:55,850 are not the ones directly in charge or directly responsible the definition of a ticket will always have 121 00:07:55,850 --> 00:07:58,750 an equal or lagging version for this record. 122 00:07:58,790 --> 00:08:04,910 And again we're only ever going to increment it on this primary service that manages this resource whenever 123 00:08:04,910 --> 00:08:08,400 we make a change to one of the attributes inside of here now. 124 00:08:08,400 --> 00:08:12,730 Quick note if managing this version stuff sounds really daunting. 125 00:08:12,840 --> 00:08:17,940 Absolutely do not sweat it turns out that Mongo D.B. and Mongoose actually have a lot of stuff built 126 00:08:17,940 --> 00:08:20,440 in to handle this versioning stuff for us. 127 00:08:20,550 --> 00:08:24,300 The only reason we're going through all this discussion is that you understand what this version stuff 128 00:08:24,300 --> 00:08:24,720 is for. 129 00:08:24,720 --> 00:08:28,530 It turns out that when we go to implement it it's actually gonna be really easy and straightforward 130 00:08:29,210 --> 00:08:36,480 but it's going to handle just about every conceivable scenario where we might throw some events at these 131 00:08:36,480 --> 00:08:42,000 order services or whatever else and the service crashes or times out where the database isn't available 132 00:08:42,240 --> 00:08:46,290 or not sends it to a service that isn't actually running and so on. 133 00:08:46,290 --> 00:08:50,940 The only thing that we really have to worry about here and it is something we'll discuss later on is 134 00:08:50,940 --> 00:08:56,850 the case in which we try to process some event and we just repeatedly repeatedly fail it over and over 135 00:08:56,850 --> 00:09:00,540 again because it is for some reason completely unprocessed on processing all. 136 00:09:00,660 --> 00:09:02,100 And that's something we will discuss later on. 137 00:09:02,460 --> 00:09:07,320 But for any kind of transient failure like a broken connection or something like that or we're getting 138 00:09:07,320 --> 00:09:12,720 events out of order this process this idea of versioning is always going to fix it. 139 00:09:13,330 --> 00:09:13,860 Okay. 140 00:09:14,000 --> 00:09:18,860 I apologize for the beginning of time for these long videos but I'm just trying to do the biggest knowledge 141 00:09:18,860 --> 00:09:20,330 dump I can. 142 00:09:20,330 --> 00:09:25,150 We're pretty much at the dawn are all done with all this kind of theory stuff. 143 00:09:25,220 --> 00:09:30,110 So now for real we can take a pause go back to the next video we're going to add in just a little bit 144 00:09:30,110 --> 00:09:35,060 more code to get understanding of this one last big feature in that's and then we'll be able to start 145 00:09:35,090 --> 00:09:38,220 implementing all this eventing stuff inside of application. 146 00:09:38,500 --> 00:09:39,000 OK. 147 00:09:39,140 --> 00:09:40,430 Quick buzz see in a minute.