1 00:00:01,240 --> 00:00:06,400 I'm taking a look at our new ticket ro handler and the update root handler and between the two of these 2 00:00:06,400 --> 00:00:08,010 they have pretty similar logic. 3 00:00:08,200 --> 00:00:09,040 Request comes in. 4 00:00:09,040 --> 00:00:10,660 We do some validation. 5 00:00:10,930 --> 00:00:16,360 We make some changes to it take a document save it and then publish an event that's inside of update. 6 00:00:16,390 --> 00:00:17,650 There is somewhere inside of new. 7 00:00:17,800 --> 00:00:19,390 We do some validation. 8 00:00:19,390 --> 00:00:24,280 We agree to take a document save it publish the event but you might notice a very small difference between 9 00:00:24,280 --> 00:00:29,180 these two root handlers and that is the presence of the awake keyword on the publisher. 10 00:00:29,180 --> 00:00:30,320 In each of them. 11 00:00:30,450 --> 00:00:35,410 Inside of my new root handler I have the await keyword on ticket create a publisher but inside of update 12 00:00:35,500 --> 00:00:37,190 I did not place that away. 13 00:00:37,190 --> 00:00:42,490 Keyword is to highlight a very interesting little issue that we might run into once our application 14 00:00:42,490 --> 00:00:44,040 starts to scale up. 15 00:00:44,180 --> 00:00:48,460 So let's take a look at a couple of diagrams and really understand what the presence of that awake you 16 00:00:48,460 --> 00:00:50,000 were does for us. 17 00:00:50,110 --> 00:00:54,700 But here's what goes on behind the scenes inside of our ticket created handler so inside there we're 18 00:00:54,690 --> 00:00:59,840 going to create a ticket document where then going to await that ticket being saved to the database. 19 00:01:00,120 --> 00:01:05,480 And because we've got that a weak keyword on the ticket save call right here. 20 00:01:05,620 --> 00:01:09,790 That means we're going to essentially sit around and wait for that record to be saved to the database 21 00:01:09,970 --> 00:01:13,120 before we continue execution of this function. 22 00:01:13,210 --> 00:01:18,470 After everything gets saved then we move on to the publisher and because we've got the awake word on 23 00:01:18,470 --> 00:01:22,790 that publisher we're going to wait for the event to be published and that's and then eventually we're 24 00:01:22,790 --> 00:01:25,460 going to send a response off to the user. 25 00:01:25,470 --> 00:01:29,840 Now let's start to think about what would happen if something went wrong with this event publishing 26 00:01:29,840 --> 00:01:34,300 process or for that matter if something went wrong with saving the record to the database as well. 27 00:01:35,750 --> 00:01:40,910 So because we've got the awake keyword on there if anything goes wrong with either saving the record 28 00:01:40,910 --> 00:01:47,990 to the database or publishing the event if we ever throw an error of any sorts from either those lines 29 00:01:47,990 --> 00:01:52,700 of code that error is going to be caught and handled by our error handling middleware. 30 00:01:52,750 --> 00:01:56,720 The error handling Middleware is going to inspect that error come up with some likely response or good 31 00:01:56,720 --> 00:01:58,930 response and send it back to the user. 32 00:01:58,940 --> 00:02:03,940 The point is if anything goes wrong the user is going to know about it they'll think about what would 33 00:02:03,940 --> 00:02:11,380 happen inside of our update handler which does not have the awake word on the publisher in that scenario. 34 00:02:11,400 --> 00:02:12,390 Here's what would go on. 35 00:02:12,420 --> 00:02:17,310 So here's the update handler we have some logic inside there to make an update to the ticket document. 36 00:02:17,310 --> 00:02:23,450 We then await saving the ticket to the document database so in that scenario once again if anything 37 00:02:23,450 --> 00:02:25,080 goes wrong with saving the ticket. 38 00:02:25,100 --> 00:02:28,550 Well errors can be thrown and it will be caught by our error handling middleware. 39 00:02:28,700 --> 00:02:34,440 But then right after that we tried to publish any event to Nats and then immediately after that because 40 00:02:34,440 --> 00:02:36,510 we do not await that publish. 41 00:02:36,600 --> 00:02:42,950 So immediately after we attempt to publish that event we then send a response directly to the user so 42 00:02:42,950 --> 00:02:44,450 we can really imagine inside this update. 43 00:02:44,450 --> 00:02:51,140 Handler this line of code runs and then essentially in the next microseconds we then immediately send 44 00:02:51,140 --> 00:02:52,270 a response back to the user. 45 00:02:53,350 --> 00:02:58,150 That means that if anything goes wrong with publishing this event to nets we don't get any opportunity 46 00:02:58,150 --> 00:03:02,710 to tell the user that some error occurred with the request though. 47 00:03:02,800 --> 00:03:07,270 What starts to get really interesting however is whether we actually need to tell the user that something 48 00:03:07,270 --> 00:03:09,490 went wrong with a published event. 49 00:03:09,490 --> 00:03:13,840 If we think about this really back inside the new request handler it might sound like a pretty obvious 50 00:03:13,840 --> 00:03:14,170 thing. 51 00:03:14,170 --> 00:03:20,180 Hey let's await the event to be published so that the user knows hey everything went as expected but 52 00:03:20,200 --> 00:03:23,010 does the user really care about this event being published. 53 00:03:23,020 --> 00:03:27,790 All we're really doing here is adding in some arbitrary latency latency to our request as we have to 54 00:03:27,820 --> 00:03:33,280 await our Nats client to reach out to that server or publish the event and get some response that says 55 00:03:33,280 --> 00:03:40,830 hey you vent publish successfully so this really does add in some tiny bit of latency to the request. 56 00:03:40,840 --> 00:03:43,420 Now what's way more relevant than all this stuff though. 57 00:03:43,570 --> 00:03:49,030 Whether or not we await for the request or not is well what really happens behind the scenes. 58 00:03:49,030 --> 00:03:53,620 If publishing any event fails let's expand on that a little bit more honestly. 59 00:03:53,720 --> 00:03:58,690 Another diagram that's going to kind of show you that this entire idea of whether or not we await publishing 60 00:03:58,690 --> 00:04:03,760 the event is not super relevant because there's actually a way bigger issue for us to start to think 61 00:04:03,760 --> 00:04:05,570 about OK. 62 00:04:05,610 --> 00:04:07,290 So here's a diagram I hear a little bit crazy. 63 00:04:07,290 --> 00:04:10,020 It is similar nature to several we've already looked at. 64 00:04:10,020 --> 00:04:14,100 So we're going to again imagine that we are thinking about some kind of banking application where we 65 00:04:14,100 --> 00:04:18,010 have a transaction service and an accounts service as well. 66 00:04:18,120 --> 00:04:21,030 The request is going to come in to the transaction service. 67 00:04:21,030 --> 00:04:27,550 It will then be handled by some kind of route and alert to create a transaction and we can imagine that 68 00:04:27,550 --> 00:04:32,590 this handler probably has some very similar logic inside of it to our ticket creation route handler 69 00:04:33,290 --> 00:04:34,360 requests is going to come in. 70 00:04:34,390 --> 00:04:40,120 It's gonna be validated processed there's going to be some code to add a transaction to a database presumably 71 00:04:40,120 --> 00:04:45,400 into some kind of transaction collection and then immediately after that we're going to attempt to emit 72 00:04:45,430 --> 00:04:51,130 an event that event will go over to that streaming server float over to the account service and so on. 73 00:04:51,860 --> 00:04:56,720 So again I want to think about what would happen if something failed with emitting this event right 74 00:04:56,720 --> 00:04:57,360 here. 75 00:04:57,470 --> 00:04:59,390 How would we somehow communicate that back to the user. 76 00:04:59,390 --> 00:05:02,630 What would the real impact on the application be though. 77 00:05:02,720 --> 00:05:08,260 Here's what we're going to imagine we successfully saved the transaction to the database and then just 78 00:05:08,260 --> 00:05:13,870 before we are able to emit an event describing the fact that the transaction was created what would 79 00:05:13,870 --> 00:05:20,950 happen if we lost our Nats connection well if we can really think about it in terms of some banking 80 00:05:20,950 --> 00:05:25,750 application we would have a very critical data integrity issue. 81 00:05:25,750 --> 00:05:28,110 Think about what the user experience would be here. 82 00:05:28,180 --> 00:05:32,290 A user would make a request to deposit some money we would then save. 83 00:05:32,320 --> 00:05:38,040 A line item inside of some database thing that a deposit was accepted and that they deposited 70 dollars. 84 00:05:38,080 --> 00:05:40,670 So that is firmly inside the database. 85 00:05:40,960 --> 00:05:45,490 But then we never met this event describing the fact that the transaction was created and that means 86 00:05:45,490 --> 00:05:48,590 that the user's account balance never gets updated. 87 00:05:49,630 --> 00:05:54,020 So on the user side they would essentially submit some money or deposit some money. 88 00:05:54,040 --> 00:05:59,170 Seventy dollars in this case they could probably then go to some transactions summary page something 89 00:05:59,170 --> 00:06:01,960 it lists all the different withdrawals and deposits they have ever made. 90 00:06:02,350 --> 00:06:07,600 And we would probably tell them that they have successfully deposited seventy dollars but because we 91 00:06:07,600 --> 00:06:13,750 never communicated this event successfully over to the account service users account balance never gets 92 00:06:13,780 --> 00:06:15,830 updated to plus 70. 93 00:06:15,910 --> 00:06:20,350 So the user would see that they deposit seventy dollars but their account balance would potentially 94 00:06:20,380 --> 00:06:21,880 still be zero. 95 00:06:21,880 --> 00:06:26,020 And as you could imagine a user would look at this and say what the heck is going on. 96 00:06:26,020 --> 00:06:30,580 You're telling me that deposit 70 dollars but my account doesn't actually have seventy dollars inside 97 00:06:30,580 --> 00:06:30,850 of it. 98 00:06:32,220 --> 00:06:37,140 So as you can see it's not really so much a question of hey how are we going to somehow tell the user 99 00:06:37,140 --> 00:06:42,100 that publishing this event failed or do we want to add in that extra latency to the request. 100 00:06:42,120 --> 00:06:43,310 That's kind of irrelevant. 101 00:06:43,350 --> 00:06:49,020 What's really relevant here is how do we somehow capture the fact that we failed entirely to emit this 102 00:06:49,020 --> 00:06:53,860 event and that we've got this critical data integrity issue between our two different services. 103 00:06:53,880 --> 00:06:56,220 That's the real question here. 104 00:06:56,220 --> 00:06:58,400 Now we understand this kind of big problem. 105 00:06:58,410 --> 00:06:59,490 Let's take a quick pause. 106 00:06:59,560 --> 00:07:02,550 We're gonna come back the next video and talk about one way of solving this.