1 00:00:00,890 --> 00:00:05,180 Well time for the moment of truth time to see if all this version stuff is going to fix our concurrency 2 00:00:05,180 --> 00:00:06,140 issues. 3 00:00:06,260 --> 00:00:10,490 So I've opened up this little test script once again as a reminder this test script is going to first 4 00:00:10,490 --> 00:00:16,280 try to create a post or me not a post but a ticket at a price of five and then going to update it to 5 00:00:16,280 --> 00:00:18,770 10 and then update it to 15. 6 00:00:18,810 --> 00:00:23,490 So we're going to expect to see all tickets eventually at a price of 15. 7 00:00:23,600 --> 00:00:28,200 I've also increased the number of requests that are made in parallel to 400. 8 00:00:28,210 --> 00:00:30,170 Now technically remember it's 400 times three. 9 00:00:30,170 --> 00:00:30,770 So really. 10 00:00:30,830 --> 00:00:36,380 Twelve hundred requests more or less in parallel again with no J s not technically in parallel truly 11 00:00:36,380 --> 00:00:41,370 but more or less running at the same time so beyond that. 12 00:00:41,380 --> 00:00:43,760 Also remember I've got two terminal windows open here. 13 00:00:43,810 --> 00:00:50,390 They're both connected directly to Mongo DB on the right hand side is my orders database on the one 14 00:00:50,390 --> 00:00:51,030 on the left hand side. 15 00:00:51,040 --> 00:00:59,020 My orders database and on the right hand side is tickets so I'm going to start up that script. 16 00:00:59,020 --> 00:01:04,060 I've got my scaffold window open over here and we're going to see some pretty interesting output beyond 17 00:01:04,070 --> 00:01:07,780 seeing a tremendous number of messages saying that we have processed some number events. 18 00:01:07,780 --> 00:01:11,230 We're actually going to start to see a couple of errors in there as well. 19 00:01:11,230 --> 00:01:16,510 We're going to expect to see an error any time some event is being processed out of order so the errors 20 00:01:16,510 --> 00:01:18,880 are going to come from this line of code right here or. 21 00:01:18,910 --> 00:01:20,620 Well really this line of code right here. 22 00:01:20,770 --> 00:01:25,690 So we're going to try to find some very specific version of a ticket if we are processing events out 23 00:01:25,690 --> 00:01:26,190 of order. 24 00:01:26,230 --> 00:01:28,340 This query is not going to find anything. 25 00:01:28,480 --> 00:01:31,390 We won't have a ticket and we'll end up throwing an error. 26 00:01:31,390 --> 00:01:37,260 Now keep in mind that when we throw the error after five seconds of not calling it message not right 27 00:01:37,270 --> 00:01:41,950 here and that streaming server is going to automatically read this batch or ream at the event that we 28 00:01:41,950 --> 00:01:43,390 fail to process. 29 00:01:43,390 --> 00:01:50,450 And so after those five seconds in theory we will have processed the second event or the first updates. 30 00:01:50,470 --> 00:01:56,350 And so when we tried to tackle this third event or the second update now we should go to find a ticket 31 00:01:56,380 --> 00:01:57,910 with the correct version. 32 00:01:57,910 --> 00:02:02,380 So how we're going to actually see that reflected inside of our scaffold logs we're gonna see a tremendous 33 00:02:02,380 --> 00:02:03,060 amount of output. 34 00:02:03,070 --> 00:02:09,580 Very quickly then a brief pause and then after about two or three seconds we're going to then see another 35 00:02:09,580 --> 00:02:15,150 small little batch of log statement stuff saying oh we have now processed this event that's we're gonna 36 00:02:15,170 --> 00:02:16,420 see in total. 37 00:02:16,420 --> 00:02:18,510 Well enough talking let's actually run this. 38 00:02:18,570 --> 00:02:21,420 I'm gonna do a node index just to run the test scripts. 39 00:02:21,520 --> 00:02:26,080 I'll then go back over to my scaffold logs are gonna see all this output and it's going to stop really 40 00:02:26,080 --> 00:02:26,500 quickly 41 00:02:30,150 --> 00:02:30,370 okay. 42 00:02:30,370 --> 00:02:33,770 There's the stop and now we're gonna wait a couple of like half a second and then boom. 43 00:02:33,790 --> 00:02:35,720 Those are all the backfilled events. 44 00:02:35,760 --> 00:02:40,820 These are all the events that fail to be processed because they were processed out of order. 45 00:02:40,870 --> 00:02:45,700 And if I even scroll back up we're gonna see some number of logs or errors inside of here as well. 46 00:02:45,730 --> 00:02:50,590 So these say ticket not found that is an instance of where we tried to process some event out of order 47 00:02:51,010 --> 00:02:55,630 that I can keep scrolling up and I'll see that yep there definitely are some number of events that were 48 00:02:55,630 --> 00:03:00,190 processed out of order or at least we attempted to now. 49 00:03:00,230 --> 00:03:05,450 The last little moment of truth here we're going to run a query on both our databases and we're going 50 00:03:05,450 --> 00:03:11,650 to expect to find the exact same number of tickets with the same price inside of both them. 51 00:03:11,660 --> 00:03:13,000 So on the orders database. 52 00:03:13,000 --> 00:03:16,050 Well let's do tickets first because this one should always be correct. 53 00:03:16,130 --> 00:03:22,880 I'll do a DV tickets fines and I'm really going to expect to see that every ticket has a price exactly 54 00:03:22,880 --> 00:03:27,750 a 15 so I find that all 400 tickets that I created. 55 00:03:27,760 --> 00:03:28,000 Yep. 56 00:03:28,020 --> 00:03:29,760 They end up at the price of 15. 57 00:03:29,800 --> 00:03:33,570 So we're going to do the same query over here on the orders database and we're going to expect to see 58 00:03:33,570 --> 00:03:38,570 exactly 400 as well which would indicate that all of our data is truly in sync. 59 00:03:38,760 --> 00:03:47,130 So I'll do a DV tickets find the price of 15 at the length and there we go. 60 00:03:47,130 --> 00:03:48,250 That's it. 61 00:03:48,270 --> 00:03:54,310 So it looks like this version tracking stuff really does solve a lot of its versioning issue so it's 62 00:03:54,310 --> 00:03:58,200 going to keep track of the aversion of all these different records we're going to use that implicitly 63 00:03:58,200 --> 00:04:01,080 to nationally order our different events. 64 00:04:01,080 --> 00:04:02,310 This really is fantastic. 65 00:04:02,310 --> 00:04:07,260 It's a great solution and make sure that even if we start to receive art events out of order for some 66 00:04:07,260 --> 00:04:14,160 crazy reason we're always going to bounce the out of order event process the one that we should be processing 67 00:04:14,250 --> 00:04:20,800 and then eventually reissue this one and apply it to our database so this really is a great solution 68 00:04:21,300 --> 00:04:25,820 but I think it'd be a little bit better if we maybe had a couple of tests as well. 69 00:04:25,900 --> 00:04:26,880 Let's take a pause right here. 70 00:04:26,890 --> 00:04:30,310 There's one or two other quick things I want to discuss and we'll continue in just a minute.