1
00:00:01,240 --> 00:00:04,240
You've now got one publisher and two listeners.

2
00:00:04,240 --> 00:00:09,430
Let's not try to emit another event by restarting the publisher so I can put in an hour s hit enter

3
00:00:10,150 --> 00:00:13,990
and then I'm going to see two console logs one from each the listeners.

4
00:00:13,990 --> 00:00:16,820
It looks like they both received that identical event.

5
00:00:16,870 --> 00:00:19,390
The one with the sequence number of fifty two.

6
00:00:19,540 --> 00:00:21,250
So we now have to these listeners.

7
00:00:21,250 --> 00:00:24,130
They both receive the exact same piece of information.

8
00:00:24,250 --> 00:00:29,500
And so presumably inside of any normal application if this was a real app they would both run some processing

9
00:00:29,560 --> 00:00:30,860
on that event.

10
00:00:30,910 --> 00:00:32,790
Now quick question for you.

11
00:00:33,040 --> 00:00:39,160
If these truly are identical services just multiple copies or two instances of the same service would

12
00:00:39,160 --> 00:00:43,000
sending them both the same exact events present an issue.

13
00:00:43,030 --> 00:00:48,470
Well maybe let's think back to the earlier project we worked on inside this course.

14
00:00:48,470 --> 00:00:55,320
I'm going to open up my code Etter very quickly back on that blog project directory OK.

15
00:00:55,330 --> 00:00:58,800
So you might remember working on the blog project inside of here.

16
00:00:58,810 --> 00:01:01,960
We allowed users to create posts and comments.

17
00:01:01,960 --> 00:01:06,310
One big problem we ran into was making sure that we could make one single request and get all of our

18
00:01:06,310 --> 00:01:11,870
posts and all of our comments all inside of one request to allow for that.

19
00:01:11,890 --> 00:01:17,140
We created something called the query service and inside the query service we had some code that would

20
00:01:17,140 --> 00:01:19,920
receive events.

21
00:01:19,980 --> 00:01:23,770
We then processed all those events inside this handle event function.

22
00:01:23,940 --> 00:01:28,650
We had some code inside there to handle post created comment created and comment updated.

23
00:01:28,650 --> 00:01:35,250
But there's one event site that I want to focus on in great detail the comment created event.

24
00:01:35,250 --> 00:01:41,370
So whenever we got an event of type comment created we took a look at the I.D. of that incoming event

25
00:01:41,400 --> 00:01:45,950
or the post idea in this case we found the post that we had previously saved.

26
00:01:46,020 --> 00:01:51,600
We then took a look at all the comments so we'd associated with it and then we pushed in a brand new

27
00:01:51,600 --> 00:01:54,190
object representing that comment.

28
00:01:54,190 --> 00:01:58,530
Now for a second let's just imagine that we were not storing these posts in memory.

29
00:01:58,530 --> 00:02:03,630
Let's imagine instead that we are storing these posts inside of some kind of Mongo DB database or some

30
00:02:03,630 --> 00:02:11,150
other similar kind of database so let's imagine what would happen if we ran this code right here or

31
00:02:11,150 --> 00:02:16,750
something like that on two separate instances of this query service.

32
00:02:16,830 --> 00:02:18,780
Well we would take the incoming event.

33
00:02:18,780 --> 00:02:24,810
We would pull off the idea content and status and then we would add that in as a brand new comment inside

34
00:02:24,900 --> 00:02:26,670
of our list of comments.

35
00:02:26,670 --> 00:02:31,260
So what would happen if we essentially ran that line of code twice.

36
00:02:31,260 --> 00:02:38,900
Well very simple we would end up with these same exact comment twice inside this comments array so very

37
00:02:38,900 --> 00:02:39,550
frequently.

38
00:02:39,590 --> 00:02:46,820
We do not want to allow an incoming event to go off to every copy of every service that we have.

39
00:02:46,820 --> 00:02:51,560
So in other words if we've got multiple copies or multiple instances of the same service usually we

40
00:02:51,560 --> 00:02:55,520
want to make sure that an incoming event is only going to go to one of them.

41
00:02:55,520 --> 00:03:00,560
So either this first copy of it right here or this first copy of it over here.

42
00:03:00,740 --> 00:03:01,990
So how can we do that.

43
00:03:02,000 --> 00:03:06,200
Well there's something built into that string server that's going to make this very easy.

44
00:03:06,200 --> 00:03:11,730
It's something called a queue group queue groups are something that we're going to be created inside

45
00:03:11,760 --> 00:03:12,990
of a channel.

46
00:03:12,990 --> 00:03:17,610
So at this point we have a channel called Ticket colon created inside this channel.

47
00:03:17,610 --> 00:03:25,970
We are going to create a queue group we can have multiple queue groups associated with one channel so

48
00:03:26,270 --> 00:03:31,010
inside of this channel we'll have our list of queue groups and we're going to give it some specific

49
00:03:31,010 --> 00:03:31,610
name.

50
00:03:31,640 --> 00:03:33,660
It could be anything we want to name it.

51
00:03:33,710 --> 00:03:38,460
It just has to be some thing that kind of more or less makes sense to us.

52
00:03:38,510 --> 00:03:44,740
Let's imagine that inside of here we create a queue group called simply my queue group we're then going

53
00:03:44,740 --> 00:03:51,070
to make sure that our order service every instance of the order service creates a subscription and joins

54
00:03:51,670 --> 00:04:02,660
that queue group like so now whenever we get an event coming into the ticket created channel not streaming

55
00:04:02,750 --> 00:04:07,940
is going to take a look at all the different queue groups we have it's then going to more or less randomly

56
00:04:08,090 --> 00:04:13,850
select one of the members out of every one of these queue groups and send the event to only one of those

57
00:04:13,850 --> 00:04:15,100
members.

58
00:04:15,110 --> 00:04:20,300
So in this case because both copies of our order service are members of my queue group that streaming

59
00:04:20,300 --> 00:04:26,450
server is going to take the event and send it off to only this service or potentially only that service

60
00:04:26,510 --> 00:04:33,520
right there now just to be clear we can still have other services that are not a member of this specific

61
00:04:33,670 --> 00:04:34,450
group.

62
00:04:34,450 --> 00:04:40,030
Let's imagine that at some point in the future maybe we have some other service some third service this

63
00:04:40,030 --> 00:04:46,070
can have a subscription of its own that is just listening to General events coming out of ticket created.

64
00:04:46,270 --> 00:04:48,350
It does not have to be a member of that queue group.

65
00:04:48,910 --> 00:04:53,470
So now whenever we have an event come in that streaming server is going to take the event and it's going

66
00:04:53,470 --> 00:04:58,510
to send off to either that service or that service because they are both members of that same queue

67
00:04:58,510 --> 00:05:04,540
group but then any other service that is just listening to the overall channel will also receive a copy

68
00:05:04,540 --> 00:05:09,850
of the event so we can really think of queue groups as limiting the number of times you send out an

69
00:05:09,850 --> 00:05:15,240
event to just members of that queue group so how do we set up a Q Group.

70
00:05:15,330 --> 00:05:18,180
Well fortunately it is really really easy.

71
00:05:18,180 --> 00:05:21,920
Back inside my editor I got to go to our listener file.

72
00:05:22,000 --> 00:05:23,820
Here's listener to us right here.

73
00:05:24,590 --> 00:05:29,710
I'm going to find where we create our subscription and as a second argument to subscribe I'm going to

74
00:05:29,720 --> 00:05:33,070
put in the name of the Q Group that I want to join.

75
00:05:33,080 --> 00:05:34,490
So again this can be any name.

76
00:05:34,520 --> 00:05:36,650
It just needs to be something that kind of makes sense to you and I.

77
00:05:37,250 --> 00:05:45,700
So in this case maybe I will create a Q Group with a name of listener Q group maybe a better format

78
00:05:45,700 --> 00:05:49,360
for this would be to name the Q Group after the type of service that is joining in.

79
00:05:49,390 --> 00:05:54,460
So in our case we've got a Q Group right here that is only going to have the copies of the order service

80
00:05:54,460 --> 00:05:55,270
joining.

81
00:05:55,300 --> 00:06:02,720
So perhaps a better name would be something like orders service Q Group or something like that if we

82
00:06:02,720 --> 00:06:06,030
wanted to take that approach then we would put in something like orders.

83
00:06:06,030 --> 00:06:10,360
Service you group that would work as well.

84
00:06:10,390 --> 00:06:14,770
The only requirement is that we make sure that every different service that tries to join into this

85
00:06:14,770 --> 00:06:18,380
Q Group has that same string okay.

86
00:06:18,390 --> 00:06:25,560
So let's now saved us all then go back over to my terminal and then back over here I'm going to once

87
00:06:25,560 --> 00:06:34,110
again publish and events an LLC that it only got sent over to one of these two listeners and I can start

88
00:06:34,110 --> 00:06:38,970
to send out multiple events and it looks like it's going to alternate between the two deciding that

89
00:06:39,000 --> 00:06:44,340
hey first I going to send one to this copy of a listener and then over to this listener if you are not

90
00:06:44,340 --> 00:06:48,840
seeing the same behavior if it looks like all the events are being sent to just one listener as opposed

91
00:06:48,840 --> 00:06:49,530
to both.

92
00:06:49,530 --> 00:06:50,990
That is totally fine as well.

93
00:06:51,090 --> 00:06:56,250
Sometimes Natsumi server is going to decide to either do a round robin or in other cases just send them

94
00:06:56,250 --> 00:06:58,430
all to one particular listener.

95
00:06:58,590 --> 00:07:03,510
And there actually are some ways we can make sure that one listener doesn't always get sent all these

96
00:07:03,510 --> 00:07:04,490
different events.

97
00:07:04,530 --> 00:07:06,060
That's something we'll take a look at in just a moment.

98
00:07:07,070 --> 00:07:07,310
Okay.

99
00:07:07,340 --> 00:07:13,680
So in total this is creating a Q Group again a Q group is created to make sure that multiple instances

100
00:07:13,680 --> 00:07:17,970
of the same service are not all going to receive the exact same event and this is going to make sure

101
00:07:18,000 --> 00:07:24,060
that we don't try to do double triple or quadruple processing on the same in coming event all right.

102
00:07:24,110 --> 00:07:28,460
So still a couple of things for us to learn so quick plans are here and I'll see you in just a minute.