1
00:00:01,310 --> 00:00:04,730
Our order created listeners is looking pretty good and we've got some tests around it.

2
00:00:04,730 --> 00:00:05,540
So that's it.

3
00:00:05,570 --> 00:00:05,990
Right.

4
00:00:06,020 --> 00:00:07,340
We're all done with the listener.

5
00:00:07,340 --> 00:00:08,890
Well come on you know by now.

6
00:00:08,900 --> 00:00:10,430
No we're not done with the listener.

7
00:00:10,430 --> 00:00:13,050
Turns out there's a hidden little issue inside of here.

8
00:00:13,070 --> 00:00:18,300
Something that could very easily bite us if we deployed this code as it stands right now.

9
00:00:18,320 --> 00:00:23,940
So let's take a look at a diagram and understand a little mistake we have inside of here OK.

10
00:00:23,970 --> 00:00:28,050
So we're going to take a look at a series of diagrams that's going to walk you through a potential flow

11
00:00:28,050 --> 00:00:28,990
inside of our app.

12
00:00:29,130 --> 00:00:33,960
And we're going to see inside of this very specific series of actions we eventually end up with some

13
00:00:33,960 --> 00:00:39,430
pretty darn inconsistent data so we're going to begin by imagining that inside of our order service

14
00:00:39,640 --> 00:00:41,980
we have replicated over a ticket.

15
00:00:42,000 --> 00:00:44,560
This is a ticket that is defined inside the order service.

16
00:00:44,560 --> 00:00:48,070
And we want to reserve it naturally to reserve a ticket.

17
00:00:48,070 --> 00:00:49,490
We're going to create an order.

18
00:00:49,570 --> 00:00:53,830
And whenever we create an order right now we are emitting an order created event.

19
00:00:53,830 --> 00:00:58,690
So this is an event that is going to be sent from the order service over to the ticket service to tell

20
00:00:58,690 --> 00:01:05,370
the ticket service that this ticket is being reserved because we just created in order so this event

21
00:01:05,370 --> 00:01:11,400
right here is going to say that our ticket I.D. sees you that's this one right here we have created

22
00:01:11,400 --> 00:01:17,610
in order to reserve it and that order has an I.D. of 80 s to the ticket service specifically the ticket

23
00:01:17,610 --> 00:01:24,000
service listener I mean the order created listener inside of there is going to find the relevant ticket.

24
00:01:24,000 --> 00:01:29,730
It's going to take that orders idea of 80 s and update the order I.D. property.

25
00:01:29,790 --> 00:01:35,100
Also remember that anytime that we make a change to a record that Mongoose update if current module

26
00:01:35,100 --> 00:01:38,140
is going to automatically increment the version number.

27
00:01:38,250 --> 00:01:39,850
And so we would go to version number one.

28
00:01:39,870 --> 00:01:47,530
Like so get let's out consider a next possible step something that could definitely happen inside of

29
00:01:47,520 --> 00:01:52,810
rap at some point in the future after this event at some point in the future maybe the user decides

30
00:01:52,840 --> 00:01:54,550
not to purchase this ticket.

31
00:01:54,550 --> 00:01:58,690
Maybe they don't pay the ticket in time or pay the order in time or whatever it is.

32
00:01:58,690 --> 00:02:03,370
But at some point time in the future we can imagine that maybe we get an order canceled event coming

33
00:02:03,370 --> 00:02:05,290
from the order service as well.

34
00:02:05,290 --> 00:02:09,970
We have not implemented this event yet but I'm sure you can imagine what this event is going to do to

35
00:02:09,970 --> 00:02:12,760
our ticket service whenever we see order canceled.

36
00:02:12,760 --> 00:02:15,610
We want to unreserved this ticket.

37
00:02:15,620 --> 00:02:22,790
So we would find the ticket with IDC Q That's this one right here and we would remove that order I.D.

38
00:02:23,510 --> 00:02:27,870
It is the presence of the order I.D. that indicates whether or not a ticket is reserved or canceled

39
00:02:27,920 --> 00:02:30,220
means don't want to reserve the ticket anymore.

40
00:02:30,290 --> 00:02:35,520
So we would just remove the order items property also because we are making a change to this ticket

41
00:02:35,580 --> 00:02:40,310
we would increment its version to 2 Okay.

42
00:02:40,360 --> 00:02:47,020
So now next possible step let's imagine that now that the ticket is unlocked and unreserved maybe the

43
00:02:47,020 --> 00:02:51,910
person who owns this ticket decides you know what I want to change the price so they make a request

44
00:02:51,910 --> 00:02:55,310
to edit the ticket and they want to change the price to 30.

45
00:02:55,390 --> 00:02:57,900
This is something we have totally built into our application.

46
00:02:57,910 --> 00:03:01,570
Definitely not outside the realm of possibility to have this happen.

47
00:03:01,870 --> 00:03:07,240
So we would find the ticket with Susie Q updated price to 30 and once again because we are making a

48
00:03:07,240 --> 00:03:08,200
change to this ticket.

49
00:03:08,320 --> 00:03:14,510
The Mongoose update if current module would automatically increment the version here to 3.

50
00:03:14,570 --> 00:03:19,250
Now do you remember as well that when the anytime we make a change to a ticket whenever we change the

51
00:03:19,250 --> 00:03:25,820
price through the request handler of ticket EDIT We also emit an event just to describe the fact that

52
00:03:25,820 --> 00:03:32,000
we have changed this price and so we can really imagine and simultaneously right after making that change

53
00:03:32,060 --> 00:03:34,540
we would emit an event that looks something like this.

54
00:03:34,640 --> 00:03:42,670
We would say for ticket i.e. Susie Q We have changed its price to 30 and the current version of this

55
00:03:42,760 --> 00:03:46,230
event or this ticket is version 3.

56
00:03:46,240 --> 00:03:47,860
So what do we do at this event.

57
00:03:47,860 --> 00:03:53,200
Well remember right now this event is going to go over to our order service because we want to keep

58
00:03:53,260 --> 00:03:56,840
all the data all the tickets between these two services in sync.

59
00:03:56,950 --> 00:03:58,890
So this event will go over to the order service.

60
00:03:58,900 --> 00:04:04,400
We're going to process it and update the order services copy of this ticket there's just one little

61
00:04:04,400 --> 00:04:11,680
issue with that so here's the same diagram I've just added in the order service at the very bottom and

62
00:04:11,680 --> 00:04:17,380
the issue here is that if we take a look at this ticket it still has a version of zero right now the

63
00:04:17,380 --> 00:04:19,570
initial version of that ticket.

64
00:04:19,660 --> 00:04:24,820
So it turns out that when we had made those updates through order it created an order canceled.

65
00:04:24,880 --> 00:04:30,940
We made changes to this ticket but we and we increment to the version but we never kind of percolated

66
00:04:30,940 --> 00:04:36,040
those changes so to speak or emitted some event to describe these changes and got that picked up by

67
00:04:36,040 --> 00:04:39,980
our order service as far as the order service is concerned.

68
00:04:40,090 --> 00:04:45,580
We have a ticket right here of version zero the order service is going to see an incoming event with

69
00:04:45,580 --> 00:04:50,480
a version of three and the order service is going to say oh I can't process this event just yet.

70
00:04:50,560 --> 00:04:53,330
It has a version of three and I'm stuck on version zero.

71
00:04:53,380 --> 00:04:59,320
So the order service is going to assume that it must be missing two events the event with version 1

72
00:04:59,410 --> 00:05:06,130
and the event with version 2 so the obvious solution here very plain and clear.

73
00:05:06,200 --> 00:05:11,540
It's just that whenever we make any kind of change that ticket through say the order created event listener

74
00:05:11,930 --> 00:05:17,300
or order canceled which we're going to put together in a little bit we have to emit an event.

75
00:05:17,300 --> 00:05:22,400
We just have to emit an event and say hey here's some new version so that all the dependent services

76
00:05:22,400 --> 00:05:26,150
can update their data and update that version number as well.

77
00:05:26,150 --> 00:05:31,010
Otherwise the version numbers are going to fall out of sync and we're not going to or as soon as we

78
00:05:31,010 --> 00:05:35,390
start to emit another event around this record all these dependent services are going to say oh I must

79
00:05:35,390 --> 00:05:39,860
be missing some events I'm going to reject this one and wait for those other events going to come in

80
00:05:40,130 --> 00:05:45,330
even though we had never emitted them so again the real lesson here is just whenever we make a change

81
00:05:45,330 --> 00:05:49,120
to a record we have to emit any event.

82
00:05:49,250 --> 00:05:54,620
So that might I think the path forward is pretty clear inside of our order create a listener.

83
00:05:54,620 --> 00:06:00,200
We are making a change to our ticket and because we are making a change we just have to emit any event

84
00:06:00,470 --> 00:06:02,110
that's pretty much it.

85
00:06:02,350 --> 00:06:07,720
Let's take a quick pause right here come back the next video add in some code to emit an event right

86
00:06:07,750 --> 00:06:13,420
after we change that ticket to just say hey this ticket spend change so quick pause I'll see you in

87
00:06:13,420 --> 00:06:13,930
just a minute.